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

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

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

@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.

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

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.

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

@andreineculau sadly does not.

+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 }}

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.

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

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.