Skip to content
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

Closed
2 of 6 tasks
classabbyamp opened this issue Oct 2, 2020 · 6 comments
Closed
2 of 6 tasks

can't get git tag annotation #1717

classabbyamp opened this issue Oct 2, 2020 · 6 comments
Assignees
Labels
Area: Git investigate Collect additional information, like space on disk, other tool incompatibilities etc. OS: Ubuntu

Comments

@classabbyamp
Copy link

classabbyamp commented Oct 2, 2020

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

  • macOS 10.15
  • Ubuntu 16.04 LTS
  • Ubuntu 18.04 LTS
  • Ubuntu 20.04 LTS
  • Windows Server 2016 R2
  • Windows Server 2019

Expected behavior
Workflow prints

SUBJECT=this is the tag subject
BODY=this is the tag body
-----BEGIN PGP SIGNATURE-----

<tag pgp signature here>
-----END PGP SIGNATURE-----

If the tag is not signed, it would not have the PGP block.

Actual behavior
Workflow prints

SUBJECT=this is the commit subject
BODY=this is the commit body

Repro steps
Example run: https://github.com/classabbyamp/git-tag-bug/actions/runs/283446508

  1. Create a new repository on Github, and clone it to your local machine.
  2. Create a workflow .github/workflows/bug.yml:
on:
  push:
    tags:
      - 'v*'

name: Showcase Bug

jobs:
  ubuntu-1804:
    name: Showcase Bug on 18.04
    runs-on: ubuntu-18.04
    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Get Tag Info
        id: get_tag
        shell: bash
        run: |
          SUBJECT=$(/usr/bin/git tag -l ${GITHUB_REF#refs/tags/} --format='%(subject)')
          echo SUBJECT=$SUBJECT
          BODY=$(/usr/bin/git tag -l ${GITHUB_REF#refs/tags/} --format='%(body)')
          echo BODY=$BODY
  ubuntu-2004:
    name: Showcase Bug on 20.04
    runs-on: ubuntu-20.04
    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Get Tag Info
        id: get_tag
        shell: bash
        run: |
          SUBJECT=$(/usr/bin/git tag -l ${GITHUB_REF#refs/tags/} --format='%(subject)')
          echo SUBJECT=$SUBJECT
          BODY=$(/usr/bin/git tag -l ${GITHUB_REF#refs/tags/} --format='%(body)')
          echo BODY=$BODY

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:

this is the commit subject

this is the commit body
  1. Tag this commit as v1.0.0 with git tag -s v1.0.0. In the annotation message, put:
this is the tag subject

this is the tag body

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

@github-actions github-actions bot added Area: Git investigate Collect additional information, like space on disk, other tool incompatibilities etc. labels Oct 2, 2020
@classabbyamp
Copy link
Author

Also note that the expected behaviour happens when running the git tag -l commands on my local arch and ubuntu machines, which have the same git version as the github workflow runners.

@vsafonkin
Copy link
Contributor

vsafonkin commented Oct 2, 2020

Hello @classabbyamp , I believe the point is that the task actions/checkout fetches only last commit object from repository by default. For example, you will see error, if you try git checkout v1.0.0. In order to avoid it, you can set the fetch-depth parameter on the task (get all history for all branches and tags):

uses: actions/checkout@v2
with:
  fetch-depth: 0

It's worked as expected: link

@classabbyamp
Copy link
Author

Setting fetch-depth: 0 did not solve it for me, but this did (it works at all fetch-depths, tested for 0-10):

uses: actions/checkout@v2
with:
  ref: ${{ github.ref }}

@vsafonkin
Copy link
Contributor

@classabbyamp , great, if your problem is resolved, you can close this issue. Thank you!

@eelco
Copy link

eelco commented Nov 11, 2021

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.

@eelco
Copy link

eelco commented Nov 11, 2021

Found the relevant issue in the checkout repo: actions/checkout#290, which has two other workarounds:

  • Use actions/checkout@v1
  • Run git fetch --force --tags

chrisd8088 added a commit to chrisd8088/git-lfs that referenced this issue Jan 24, 2025
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Git investigate Collect additional information, like space on disk, other tool incompatibilities etc. OS: Ubuntu
Projects
None yet
Development

No branches or pull requests

4 participants