-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
can't get git tag annotation #1717
Comments
Also note that the expected behaviour happens when running the |
Hello @classabbyamp , I believe the point is that the task
It's worked as expected: link |
Setting uses: actions/checkout@v2
with:
ref: ${{ github.ref }} |
@classabbyamp , great, if your problem is resolved, you can close this issue. Thank you! |
I’m running into the same issue and this had me stumped for a solid hour. I do feel that this is (still) a bug. Interestingly, it also only happens for the tag that is being checked out, older tags do have their body available. |
Found the relevant issue in the checkout repo: actions/checkout#290, which has two other workarounds:
|
In commit df6e49c of PR git-lfs#5243 we added a step to all of the jobs in our CI and release GitHub Actions workflows to work around the problem described in actions/checkout#290 and actions/checkout#882. This step, which only executes if the job is running due to the push of a new tag, performs a "git fetch" command of the tag's reference to ensure that the local copy is identical to the remote one and has not been converted from an annotated tag into a lightweight one. Starting with v2 of the actions/checkout action, annotated tags are by default replaced with lightweight ones, which then causes any subsequent "git describe" commands to return an incorrect value. Since we depend on the output of "git describe" in several places in our workflows to generate the appropriate version name for our release artifacts, we need to ensure we have the full annotated tag for the current reference rather than a lightweight one. Recently, in commit 9c3fab1 of PR git-lfs#5930, we strengthened the security of our GitHub Action workflows by setting the "persist-credentials" option of the actions/checkout action to "false", so that any cached Git credentials are removed at the end of that step. While this causes no problems when our CI workflow runs after a branch is pushed, as is the case for new PRs, when we push a new tag the "git fetch" step now fails as it depends on the cached Git credentials from the actions/checkout step. We could use the GITHUB_TOKEN Action secret to temporarily set an appropriate HTTP Authorization header to make the "git fetch" command succeed. However, a more straightforward solution exists whereby we specify explicitly the reference we want to check out using the "ref" option of the actions/checkout action. This causes the action to fetch the reference such that if the reference is an annotated tag, it remains one and is not converted into a lightweight one. For reference, see: actions/checkout#882 (comment) actions/runner-images#1717 (comment) h/t classabbyamp and xenoterracide for documenting this workaround
Description
git tag -l --format='%(subject)' <tag name>
returns the commit message, not the tag subject.git tag -l --format='$(body)' <tag name>
returns the commit body (if it exists), not the tag body (if it exists).Related to actions/runner#712
Area for Triage: Git
Question, Bug, or Feature?: Bug
Virtual environments affected
Expected behavior
Workflow prints
If the tag is not signed, it would not have the PGP block.
Actual behavior
Workflow prints
Repro steps
Example run: https://github.com/classabbyamp/git-tag-bug/actions/runs/283446508
.github/workflows/bug.yml
:This job will demonstrate the issue on both the 18.04 and 20.04 runners.
3. Stage, commit, and push this file
4. Create a file, stage, and commit it. In the commit message, put:
v1.0.0
withgit tag -s v1.0.0
. In the annotation message, put:Signing is not required for this behaviour, only that the tag is annotated, so
git tag -a v1.0.0
would also work. The only difference in expected behaviour would be not having the PGP block in the body output.6. Push the commit and the tag
7. Observe the results of the action
The text was updated successfully, but these errors were encountered: