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

Preserve tag annotations #290

Open
Tracked by #124
martinthomson opened this issue Jun 26, 2020 · 24 comments · May be fixed by #1506
Open
Tracked by #124

Preserve tag annotations #290

martinthomson opened this issue Jun 26, 2020 · 24 comments · May be fixed by #1506

Comments

@martinthomson
Copy link

martinthomson commented Jun 26, 2020

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
Copy link

morrone commented Jul 17, 2020

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

@martinthomson
Copy link
Author

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
Copy link
Contributor

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

@morrone
Copy link

morrone commented Jul 20, 2020

@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
Copy link
Contributor

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

@Stanzilla
Copy link

Stanzilla commented Aug 13, 2020

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
Copy link

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

@Stanzilla
Copy link

@andreineculau sadly does not.

charleskorn added a commit to batect/batect that referenced this issue Aug 25, 2020
@Envek
Copy link

Envek commented Aug 25, 2020

+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
Copy link
Author

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
Copy link

bixu commented Aug 28, 2020

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

@haizaar
Copy link

haizaar commented Oct 6, 2020

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
Copy link

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
Copy link

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
Copy link

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

@ericcornelissen
Copy link

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
Copy link
Author

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.

avdv added a commit to avdv/scalals that referenced this issue Nov 4, 2020
avdv added a commit to avdv/scalals that referenced this issue Nov 5, 2020
* ensure to fetch tag information (see issue [#290])

[#290]: actions/checkout#290
avdv added a commit to avdv/scalals that referenced this issue Nov 5, 2020
* ensure to fetch tag information (see issue [#290])

[#290]: actions/checkout#290
avdv added a commit to avdv/scalals that referenced this issue Nov 5, 2020
* ensure to fetch tag information (see issue [#290])

[#290]: actions/checkout#290
behrisch added a commit to eclipse-sumo/sumo that referenced this issue Dec 1, 2020
marquiz added a commit to marquiz/node-feature-discovery that referenced this issue Dec 7, 2020
V2 handles tags incorrectly
(actions/checkout#290) and the easiest
solution is to simply switch to v1.
rebornplusplus added a commit to rebornplusplus/chisel that referenced this issue Aug 10, 2023
Create binaries on push, tag creation and when a release
has been published. Create an archive with the binary, and
attach it to the release if a release is published. In all
cases, attach the archive in the workflow run as an artifact.

The actions/checkout@v3 action overwrites annonated tag with
lightweight tags breaking ``git describe``. See [1], [2].
This commit adds a workaround to restore the latest tag to
it's original state.

References:
- [1] actions/checkout#882
- [2] actions/checkout#290
jnsgruk pushed a commit to canonical/chisel that referenced this issue Aug 10, 2023
Create binaries on push, tag creation and when a release
has been published. Create an archive with the binary, and
attach it to the release if a release is published. In all
cases, attach the archive in the workflow run as an artifact.

The actions/checkout@v3 action overwrites annonated tag with
lightweight tags breaking ``git describe``. See [1], [2].
This commit adds a workaround to restore the latest tag to
it's original state.

References:
- [1] actions/checkout#882
- [2] actions/checkout#290
vslavik added a commit to vslavik/winsparkle that referenced this issue Sep 1, 2023
tim-janik added a commit to tim-janik/gh-testing that referenced this issue Sep 6, 2023
tim-janik added a commit to tim-janik/anklang that referenced this issue Sep 7, 2023
Fix actions/checkout@v3 and actions/checkout@v4 messing up the annotation of
the currently fetched tag, even with fetch-depth:0, see: actions/checkout#290

Signed-off-by: Tim Janik <[email protected]>
tim-janik added a commit to tim-janik/anklang that referenced this issue Sep 7, 2023
* release-fixes:
  MISC: mknews.sh: print latest NEWS.md version with `misc/mknews.sh --version`
  GITHUB: workflows/release.yml: set prerelease:false for annotated tags
	Fix actions/checkout@v3 and actions/checkout@v4 messing up the annotation of
	the currently fetched tag, even with fetch-depth:0, see: actions/checkout#290
  MISC: mknews.sh: for release tags, copy news section from NEWS.md

Signed-off-by: Tim Janik <[email protected]>
detsch pushed a commit to detsch/fioctl that referenced this issue Sep 22, 2023
As per:

 actions/checkout#290

Our releases weren't getting the correct tag embedded into the binary

Signed-off-by: Andy Doan <[email protected]>
Rycieos added a commit to Rycieos/actions-checkout that referenced this issue Oct 6, 2023
Currently, a check is done after fetch to ensure that the repo state has
not changed since the workflow was triggered. This check will reset the
checkout to the commit that triggered the workflow, even if the branch
or tag has moved since.

The issue is that the check currently sees what "object" the ref points
to. For an annotated tag, that is the annotation, not the commit. This
means the check always fails for annotated tags, and they are reset to
the commit, losing the annotation. Losing the annotation can be fatal,
as `git describe` will only match annotated tags.

The fix is simple: check if the tag points at the right commit, ignoring
any other type of object. This is done with the <rev>^{commit} syntax.

From the git-rev-parse docs:
> <rev>^{<type>}, e.g. v0.99.8^{commit}
>  A suffix ^ followed by an object type name enclosed in brace pair
>  means dereference the object at <rev> recursively until an object of
>  type <type> is found or the object cannot be dereferenced anymore (in
>  which case, barf). For example, if <rev> is a commit-ish,
>  <rev>^{commit} describes the corresponding commit object. Similarly,
>  if <rev> is a tree-ish, <rev>^{tree} describes the corresponding tree
>  object.  <rev>^0 is a short-hand for <rev>^{commit}.

If the check still fails, we will still reset the tag to the commit,
losing the annotation. However, there is no way to truly recover in this
situtation, as GitHub does not capture the annotation on workflow start,
and since the history has changed, we can not trust the new tag to
contain the same data as it did before.

Fixes actions#290
Closes actions#697
@Rycieos Rycieos linked a pull request Oct 6, 2023 that will close this issue
kui added a commit to kui/knavi that referenced this issue Nov 4, 2023
The checkout action does not work with annotated tags.
See actions/checkout#290.
tim-janik added a commit to tim-janik/anklang that referenced this issue Jan 26, 2024
…ated tag

Upgrade to actions/[email protected] and Fix actions/checkout messing up
checkouts of annotated tags; actions/checkout#290

Also fetch submodule upfront.

Signed-off-by: Tim Janik <[email protected]>
tim-janik added a commit to tim-janik/anklang that referenced this issue Jan 26, 2024
* branch-check:
  GITHUB: workflows/testing.yml: update to actions/upload-artifact@v4
  GITHUB: workflows/testing.yml: only build & upload docs from tim-janik/anklang
  GITHUB: workflows/testing.yml: update to actions/cache@v4
  GITHUB: workflows/testing.yml: use actions/[email protected], fix annotated tag
	Upgrade to actions/[email protected] and Fix actions/checkout messing up
	checkouts of annotated tags; actions/checkout#290
	Also fetch submodule upfront.
  GITHUB: workflows/testing.yml: remove Release-Upload run
  MISC: Makefile.mk: fix script v2.34 invocation
	The util script from util-linux 2.34 (focal) has no `-O` option.
  GITHUB: workflows/testing.yml: add `make branch-check` and check errors in PRs
  MISC: Makefile.mk: add branch-check rule, $BRANCH_CHECK_EXIT holds error status
  GITHUB: workflows/testing.yml: disable CI on tag pushes
  MISC: mknews.sh: show git command line
  MISC: Makefile.mk: fix missing CLEANDIRS

Signed-off-by: Tim Janik <[email protected]>
kirasok added a commit to kirasok/random_password_generator that referenced this issue Feb 3, 2024
Stanzilla added a commit to WeakAuras/WeakAuras2 that referenced this issue Feb 7, 2024
hikari-no-yume added a commit to touchHLE/touchHLE that referenced this issue Apr 2, 2024
This reverts commit 083ace1.

The intention was to allow tagging a release and then `git describe`
would pick up the new tag name, but unfortunately that doesn't work:
actions/checkout#290

Instead re-running a trunk build is the only way. So, there's no point
letting tags trigger builds.
@hikari-no-yume
Copy link

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.

alexcrichton added a commit to alexcrichton/wasi-sdk that referenced this issue Apr 12, 2024
My release attempt in WebAssembly#408 did not go well because the release artifacts
were not named correctly. This fixes an issue described by
actions/checkout#290 where checkouts of annotated tags overwrite the
annotation which breaks `git describe`. That means that version
detection is broken in CI during releases which causes artifacts to have
the wrong information.

This applies the workaround described in that issue to `git fetch --tags
--force` after the checkout step to undo the overwrite done in the
checkout step.
abrown pushed a commit to WebAssembly/wasi-sdk that referenced this issue Apr 15, 2024
My release attempt in #408 did not go well because the release artifacts
were not named correctly. This fixes an issue described by
actions/checkout#290 where checkouts of annotated tags overwrite the
annotation which breaks `git describe`. That means that version
detection is broken in CI during releases which causes artifacts to have
the wrong information.

This applies the workaround described in that issue to `git fetch --tags
--force` after the checkout step to undo the overwrite done in the
checkout step.
miguelbaldi pushed a commit to miguelbaldi/krust that referenced this issue May 1, 2024
miguelbaldi pushed a commit to miguelbaldi/krust that referenced this issue May 1, 2024
nickg added a commit to nickg/nvc that referenced this issue Jul 19, 2024
nickg added a commit to nickg/nvc that referenced this issue Jul 21, 2024
nickg added a commit to nickg/nvc that referenced this issue Jul 21, 2024
nickg added a commit to nickg/nvc that referenced this issue Jul 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.