Preserve tag annotations #290
Comments
|
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: |
|
@martinthomson does the input |
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. |
|
|
|
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 sadly does not. |
|
+1 on preserving tag annotations. 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 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 |
|
Also seeing that |
|
I only needed to |
|
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 |
|
Same here, exact same scenario as chrislambe described. I can also confirm that |
|
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 |
|
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. |
* ensure to fetch tag information (see issue [#290]) [#290]: actions/checkout#290
* ensure to fetch tag information (see issue [#290]) [#290]: actions/checkout#290
* ensure to fetch tag information (see issue [#290]) [#290]: actions/checkout#290
V2 handles tags incorrectly (actions/checkout#290) and the easiest solution is to simply switch to v1.
a9a6e9e and ea43df2 removed a step that was probably intended to work around actions/checkout#290 and actions/checkout#882, but broke the CI build if anyone used a lightweight tag (because these fetch lines actually shallow the tag depth to 1). This commit attempts to thread the needle by making this workaround conditional only to releases, where (if the person doing the release has followed the steps correctly), there is guaranteed to be an annotated tag at depth 1 in the tag history. (If I'm parsing the checkout bugs correctly, they only trigger on a tag action anyways.)
a9a6e9e and ea43df2 removed a step that was probably intended to work around actions/checkout#290 and actions/checkout#882, but broke the CI build if anyone used a lightweight tag (because these fetch lines actually shallow the tag depth to 1). This commit attempts to thread the needle by making this workaround conditional only to releases, where (if the person doing the release has followed the steps correctly), there is guaranteed to be an annotated tag at depth 1 in the tag history. (If I'm parsing the checkout bugs correctly, they only trigger on a tag action anyways.) (cherry picked from commit 8713efd)
see detail: actions/checkout#290 Signed-off-by: Frank Li <Frank.Li@nxp.com>
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
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
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
See actions/checkout#290 for why this helps.
…tion of the fetched tag: actions/checkout#290 Signed-off-by: Tim Janik <timj@gnu.org>
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 <timj@gnu.org>
* 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 <timj@gnu.org>
As per: actions/checkout#290 Our releases weren't getting the correct tag embedded into the binary Signed-off-by: Andy Doan <andy@foundries.io>
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
The checkout action does not work with annotated tags. See actions/checkout#290.
…ated tag Upgrade to actions/checkout@v4.1.1 and Fix actions/checkout messing up checkouts of annotated tags; actions/checkout#290 Also fetch submodule upfront. Signed-off-by: Tim Janik <timj@gnu.org>
* 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/checkout@v4.1.1, fix annotated tag Upgrade to actions/checkout@v4.1.1 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 <timj@gnu.org>
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.
|
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. |
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.
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.
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.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.The text was updated successfully, but these errors were encountered: