Don't overwrite annotated tags with commit object #697
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When checking out a repository with full history, a full clone is done and then the ref is finally updated to point to the commit that caused the workflow to be run. Normally, this is a good protection against someone pushing to the repository twice in short succession, but it causes problems with annotated tags. Specifically, because the entry in refs/tags is set to the commit hash, if an annotated tag was used, the tag is turned merely into a lightweight one, which breaks `git describe`. Every other tag in the repository will continue to remain a valid annotated tag except the one for which the workflow was invoked, which is not what the user expected. Let's work around this by not performing a fetch if what we're fetching is a tag. Technically, annotated tags can be anywhere in the hierarchy at any ref, but this should work as a suitable heuristic for now. Note that the proper solution would be to expose the revision of the actual object and check against that instead of the commit, but it doesn't presently appear that that information is exposed. Also, we explicitly do not case-fold since Git refs are case sensitive.
2 tasks
|
I keep running into this bug. This is the standard workaround which is in all our cockpit projects, as well as my own now: - name: Workaround for https://github.com/actions/checkout/pull/697
run: git fetch --force origin $(git describe --tags):refs/tags/$(git describe --tags) |
martinpitt
added a commit
to martinpitt/umockdev
that referenced
this pull request
Jul 2, 2022
martinpitt
added a commit
to martinpitt/umockdev
that referenced
this pull request
Jul 2, 2022
martinpitt
added a commit
to martinpitt/python-dbusmock
that referenced
this pull request
Jul 19, 2022
Rycieos
added a commit
to Rycieos/actions-checkout
that referenced
this pull request
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
martinpitt
added a commit
to mpitt-test-org/python-dbusmock
that referenced
this pull request
Feb 23, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When checking out a repository with full history, a full clone is done and then the ref is finally updated to point to the commit that caused the workflow to be run. Normally, this is a good protection against someone pushing to the repository twice in short succession, but it causes problems with annotated tags.
Specifically, because the entry in refs/tags is set to the commit hash, if an annotated tag was used, the tag is turned merely into a lightweight one, which breaks
git describe. Every other tag in the repository will continue to remain a valid annotated tag except the one for which the workflow was invoked, which is not what the user expected.Let's work around this by not performing a fetch if what we're fetching is a tag. Technically, annotated tags can be anywhere in the hierarchy at any ref, but this should work as a suitable heuristic for now.
Note that the proper solution would be to expose the revision of the actual object and check against that instead of the commit, but it doesn't presently appear that that information is exposed. Also, we explicitly do not case-fold since Git refs are case sensitive.
This mostly addresses #290.