ci: push git tag before publishing release#2861
ci: push git tag before publishing release#2861tjones60 wants to merge 1 commit intomicrosoft:mainfrom
Conversation
There was a problem hiding this comment.
Pull request overview
Updates the Flowey GitHub release publishing node to create and push a git tag before creating a (draft) GitHub release, aiming to ensure the release is tied to the intended commit.
Changes:
- Create an annotated git tag for the release version.
- Push the tag to
originprior to invokinggh release create.
| // create the tag to make sure the release is associated with the right commit | ||
| flowey::shell_cmd!(rt, "git tag -a {tag} -m {title}").run()?; | ||
| flowey::shell_cmd!(rt, "git push origin {tag}").run()?; |
There was a problem hiding this comment.
These git tag/git push commands assume the step is executing inside the correct git checkout and that origin is configured with push credentials. publish_gh_release doesn’t take a repo directory/commit SHA, and in the current pipeline the OpenVMM repo is checked out with persist_credentials: false and allow_persist_credentials: false, so git push is expected to fail (or tag the wrong repo). Consider either (a) adding a repo_dir input and chdir before tagging, and ensuring the checkout allows persisted credentials, or (b) avoiding git push entirely by using the GitHub API/gh release create --target <sha> to bind the release to a specific commit without requiring git auth.
| let draft = draft.then_some("--draft"); | ||
|
|
||
| // create the tag to make sure the release is associated with the right commit | ||
| flowey::shell_cmd!(rt, "git tag -a {tag} -m {title}").run()?; |
There was a problem hiding this comment.
Creating an annotated tag (git tag -a ... -m ...) requires user.name/user.email to be configured; CI environments often don’t set these by default, which can cause the step to fail before publishing. If the message isn’t required, consider using a lightweight tag instead, or explicitly setting tagger identity via env/git config within the step.
| flowey::shell_cmd!(rt, "git tag -a {tag} -m {title}").run()?; | |
| flowey::shell_cmd!(rt, "git tag {tag}").run()?; |
benhillis
left a comment
benhillis
left a comment
There was a problem hiding this comment.
I wonder if it might be better to have a flow where:
- The CI job pushes the tag
- A separate workflow publishes the release (triggered by tags)
benhillis
left a comment
benhillis
left a comment
There was a problem hiding this comment.
I've decided I am ok with this approach, but I think copilot found a couple real issues that should be fixed.
Push a git tag before publishing a (draft) GitHub release to ensure the right commit gets associated with the release even if another PR is merged before the draft is published.