ci: lighten PR validation and change release process #23
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
cc @antifuchs and @purcell for comments here :D |
Closed
antifuchs
reviewed
May 7, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
So, with the initial transfer for #19 out of the way, this PR is intended to make some changes to contribution and the release process, some of them discussed in #20 with @purcell.
Laundry list of changes in this PR:
CODEOWNERSupdated to thenix-community/nix-ts-modeteam, and not just myselfPR title validation removed as a requirement. I do still like the conventional commit spec, and I'd prefer it to unreadable commit messages, but the
NO-ISSUEcruft is a real concern. At the very least I'd like to eliminate theNO-ISSUE/issue number requirement but still require conventional spec type.With PR title validation removed, automatic versioning doesn't make sense (and never really did with a repo of this size). Automatic versioning actions are replaced with simple release and changelog generation actions caused by version tagging events.
Enable Dependabot version updating for Github Actions, to keep them up to date
Deduplicate the lint/test actions to use on
trunkafter appropriate commits and repoint the status badge in theREADMEto the correct repoOpen questions I have for discussion:
How do we want to restrict release tagging? Currently, the action in this PR will generate a changelog and release off of any tag. Obviously anyone in the
nix-ts-modeteam in theory will have permissions to push whatever tags. Do we want to restrict releasing to tags matching a semantic version (i.e.v.XX.XX.XX) exactly, which would leave room for tags for other uses? Do we really even care given how low traffic this repo is right now?EDIT: It occurs to me that we could easily use protected tag patterns for this - protect semver tags for individuals with release permissions, and that should solve the problem rather nicely
Looks like other projects in
nix-communitytend to use Renovate rather than Dependabot - I prefer renovate myself, but did dependabot initially as it's arguably less configuration. Any preference folks have?