[FC-41962] jenkins: always resolve tags to rev of the commit that got tagged #201
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
Ma27
force-pushed
the
FC-41962-tag-resolution
branch
from
edfd2d2
to
7f265fd
Compare
FC-41962 Closes #200 Previously, we always resolved tags to the commit rev. However if this failed, there was a fallback to the rev of the tag (the output of `git ls-remote` without the `^{}` modifier). This is a problem in a deployment where we rely on the rev being the commit rev since that's part of the S3 url where the frontend assets are stored. The reason for the fallback that lead to such a deployment error was a timing issue where the first `ls-remote` failed like this ssh: Could not resolve hostname gitlab.customer.com: Try again fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. and the second one (resolving to the tag's rev) succeeded. We now call `ls-remote` without the `^{}` modifier and check if the refspec got resolved to a tag (i.e. `refs/tags/...`). If that's the case, a second `ls-remote` is issued with the `^{}` modifier to get the rev of the commit that got tagged. If this second call fails, we fail hard to make sure we don't get incorrect results silently.
Ma27
force-pushed
the
FC-41962-tag-resolution
branch
from
7f265fd
to
4683e28
Compare
Ma27
commented
Dec 2, 2024
| if full_refspec.startswith("refs/tags/"): | ||
| ls_remote_tag = git_ls_remote(url, f"{version}^{{}}") | ||
| if ls_remote_tag: | ||
| rev = ls_remote_tag[0] |
There was a problem hiding this comment.
Tags don't necessarily have their own revision as I've just learned.
So this code would break with such revs.
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.
FC-41962
Closes #200
Previously, we always resolved tags to the commit rev. However if this failed, there was a fallback to the rev of the tag (the output of
git ls-remotewithout the^{}modifier).This is a problem in a deployment where we rely on the rev being the commit rev since that's part of the S3 url where the frontend assets are stored. The reason for the fallback that lead to such a deployment error was a timing issue where the first
ls-remotefailed like thisand the second one (resolving to the tag's rev) succeeded.
We now call
ls-remotewithout the^{}modifier and check if the refspec got resolved to a tag (i.e.refs/tags/...). If that's the case, a secondls-remoteis issued with the^{}modifier to get the rev of the commit that got tagged. If this second call fails, we fail hard to make sure we don't get incorrect results silently.