Add justfile recipes to help with releasing
#2077
Merged
Conversation
This file contains hidden or 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
This adds three recipes to the `justfile`. Two of these recipes trigger the release workflow. 1. `unique-v-tag`, which delegates to a script, looks at tags that point to `HEAD`, reports an error if none, or more than one, of them are named starting with `v`, and otherwise outputs the name of the unique `v*` tag that it found. 2. `run-release-workflow` triggers the `release.yml` workflow for a tag obtained via `unique-v-tag`. By default, it runs it on the `GitoxideLabs/gitoxide` repository. This can be adjusted by setting the `GH_REPO` environment variable, as usual for `gh`. It can also be adjusted by passing an optional argument to the recipe (which takes precedence over `GH_REPO` if set). 3. `roll-release` runs `cargo smart-release`, forwarding its arguments to it, and then runs the `release.yml` workflow via `run-release-workflow`. Because all arguments to `roll-release` are passed to `cargo smart-release`, the repository to run `release.yml` on cannot be specified as an argument to `roll-release`, but `GH_REPO` can still be used to customize it. (Also, since `roll-release` is meant to be used when actually creating releases and publishing them, it's not expected to run on forks nearly as often as the upstream.) See GitoxideLabs#1970.
For now, this makes it so the `workflow_dispatch` event has to be used to run the `release.yml` workflow, except for fake testing releases (tags that end in `-DO-NOT-USE`). As noted in the explanatory comment, the `push` event rarely if ever occurs when tags are pushed to the `GitoxideLabs/gitoxide` repository. It is uncommon for a `gitoxide` crate release to be tagged at a commit that does not also have three or more library crates tagged. But `cargo smart-release` pushes all relevant tags at once, and GitHub Actions currently does not register a `push` event when more than three tags are pushed together. So the `release.yml` workflow is run via `workflow_dispatch` instead. The preceding commit adds `justfile` recipes to make it easier to trigger `release.yml` via `workflow_dispatch`. But this runs the risk that, in the rare case that there are few enough tags pushed for the `push` trigger to work, the workflow might be run more than once for the same release. Therefore, this prevents `push` from ever triggering the workflow for tags representing actual releases. See GitoxideLabs#1970 for some other details. (Allowing `push` to still work in testing makes it easier to test in a fork without risking accidentally triggering the workflow in the upstream repository. So the pattern is narrowed to still allow that, rather than being removed altogether, at least for now.)
Byron
approved these changes
Jul 14, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
As described in #1970, the
release.ymlworkflow can rarely (if ever) trigger onpush, becausecargo-smart-releaseusually pushes more than three tags at a time, as used here.This makes two changes:
justfileto make it easier to trigger the workflow viaworkflow_dispatch.pushevent from triggering the workflow except for testing tags, so it's not accidentally triggered twice when using the new recipes.There are substantial further details in the commit messages. I have tested everything in my fork, for various scenarios--for example, here's one of the runs--except I have only slightly tested
roll-release. It may be that something likejust roll-release -ewill usually be sufficient when releasing, I am not sure.I am not sure about the
roll-releaserecipe as currently written. If one were to runjust roll-release, then it would do a dry-run release, but then attempt to run the actual release workflow.cargo smart-releasefor a dry run (even if it would have just one command), with theroll-releaserecipe without passing-e/--execute, to discourage such usage where it would not make sense to trigger the workflow. Maybe theroll-releaserecipe should pass-e/--execute.roll-releasefor a dry-run should not be discouraged: if there is nov*tag atHEAD, then therun-release-workflowrecipe will look for a uniquev*tag via theunique-v-tagrecipe, which will fail, and nogh workflowcommand will be invoked.v*tag at the tip of a branch before runningcargo smart-releasewith the intent that new commits will be created with changelogs and a release will be performed. This seems unlikely, but I don't know of any fundamental reason it could not happen. (For example, a preceding just-completed release of at least one crate could have been yanked due to a SemVer-related problem.) If that happened, then we could wrongly rerunrelease.ymlon av*tag.In view of my uncertainty as to how safe and usable the current design is, I'll wait for a review before merging.
Edit: Clarified and fixed some incorrect wording in the above bullet points.