Preserve tag annotations

[martinthomson]

The technique this tool uses for checking out tags only preserves the relation between tag and ref, not any annotations created with git tag -a.

git fetch origin +$HASH:refs/tags/$TAG
git checkout -f refs/tag/$TAG

I have a CI action that depends on information from annotated tags. Specifically, the name of the person who applied the tag: git tag --list --points-at HEAD --format '%(taggeremail)' (I can't use ${{ github.actor }} for reasons).

The workaround is to run git fetch -f origin ${{ github.ref }}:${{ github.ref }}. But it would be better not to need this workaround.

[morrone]

Agreed! This breaks the "git describe" command too. We need tags to be in their correct original form.

[martinthomson]

I realize now that this is complicated by a desire to checkout the specific code identified by the hash when the tag has been re-applied on the repository. I would be happy to have an option that would cause the checkout to fail if the hash didn't match.

For example:

git fetch origin refs/tags/$TAG
[ `git rev-parse refs/tags/$TAG` != $HASH ] || fail
git checkout -f refs/tag/$TAG

[ericsciple]

@martinthomson does the input depth: 0 help? It will cause all history for all branches and tags to be fetched?

[morrone]

@martinthomson does the input depth: 0 help? It will cause all history for all branches and tags to be fetched?

I didn't try 0, but I tried "fetch-depth: 2000" at one point. It fetched the other tags in that history correctly, but if the thing that triggered the workflow was itself an annotated tag, that one tag will still be converted from an annotated tag into a lightweight tag.

[ericsciple]

fetch-depth: 0 triggers a different behavior. Curious if that solves the issue?

[Stanzilla]

It does not solve the issue, I ran into this today. Looks like the action is not using the tag itself, just the commit the tag points to.

[andreineculau]

fetch-depth: 0 does solve the issue. I don't see how it wouldn't because it fetch all branches, all tags

[Stanzilla]

@andreineculau sadly does not.

[Envek]

+1 on preserving tag annotations. fetch-depth: 0 alone doesn't help, git fetch --tags --force does help.

name: Create release from annotated tag
on: push
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0 # Doesn't help
      - name: "Extract data from tag: version, message, body"
        id: tag
        run: |
          git fetch --tags --force # Retrieve annotated tags. THIS TRICK REALLY HELPS
          echo ::set-output name=subject::$(git for-each-ref $GITHUB_REF --format='%(contents:subject)')
          # …
      - name: Create Release
        uses: actions/create-release@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          tag_name: ${{ github.ref }}
          release_name: ${{ steps.tag.outputs.subject }}

[martinthomson]

That's the same workaround I originally suggested, just more broadly targets (all tags, not just one). As you say --depth 0 has no effect.

The main problem is that the code fetches using a hash and then re-applies its own tag if the build was initiated as a result of applying a tag. That's also why you need to add --force, because you need to overwrite that bad tag. Hence my suggestion to fetch the tag rather than applying it, along with a check that the tag still points to the fetched content.

[bixu]

Also seeing that fetch_depth: 0 doesn't work for all Actions that handle/search for tags in the repo history.

[haizaar]

I only needed to git describe --always to discover the latest tag since I'm release docker images myself, and indeed in GH Actions it was discovering one-before-the-current tags. In my case it was another to add --tags to git describe to make it consider non-annotated tags well.
While it was an easy workaround I believe there is way too much details involved in getting this work properly.

[chrislambe]

This bit me as well. We use annotated tags in our build/release process and this was a little tough to track down. Another confirmation that fetch-depth: 0 does not address this. Adding git fetch --force --tags as an additional build step after checkout seems to be a valid workaround, at least for us.

[ericcornelissen]

Same here, exact same scenario as chrislambe described. I can also confirm that fetch-depth: 0 doesn't help, but adding git fetch --force --tags does.

[Stanzilla]

You can also just revert to checkout@v1 it does not really have any downsides

[ericcornelissen]

You can also just revert to checkout@v1 it does not really have any downsides

Thanks for the suggestion, I can confirm that works fine as well. Though, I would argue that it has the downside of probably receiving support for less amount of time.

On the other hand, I don't see any downsides to using git fetch --force --tags. Am i missing something? I guess the overhead can get a bit high for large projects?

[martinthomson]

The downside is that if the tag has moved then it will no longer be attached to the commit that you have checked out. For that, my personal preference is for the situation to be detected and the build aborted. It shouldn't happen very often.

[hikari-no-yume]

I got bitten by this yesterday. The solution offered in #1506 looks like a good compromise to me. I hope that'll be merged eventually.