Open asbjornu opened 1 month ago
I'm facing this issue atm. In Bitbucket, I can select any commit, then run a pipeline that checks out that commit, however I am getting this same exception. Is there any workaround? I need to be able to rebuild older versions too. I have tried to create a new branch that includes only those commits that the older version had before, then I don't face this issue (there's then another problem with tags, version is taken from the latest tag from main branch, not the latest tag that is in my branch)..
In a Unix terminal, the question "what is the highest tag currently pointing at the current commit" can be answered by the following command: git tag --points-at "${sha}" | sort -n | tail -1
What if you have 2 tags on the same commit, which one should you pick? What if the picked tag is not the one you want?
In Bitbucket, I can select any commit, then run a pipeline that checks out that commit, however I am getting this same exception.
@arihannu, for a random commit without any associated tags, I'm not sure what GitVersion should do. It at least needs to know which branch the build commit should be treated as. Should GitVersion just assume that a detached HEAD
with no version tags pointing to it is to be treated as a commit on main
? Or does detached HEAD
need to be configurable with its own branch configuration? Thoughts @HHobeck?
What if you have 2 tags on the same commit, which one should you pick? What if the picked tag is not the one you want?
Elsewhere in GitVersion, we pick the highest version number available. Wouldn't that make sense in this case as well, @arturcic?
I suspect that should be done in TaggedCommit strategy then
@arihannu, for a random commit without any associated tags, I'm not sure what GitVersion should do. It at least needs to know which branch the build commit should be treated as. Should GitVersion just assume that a detached
HEAD
with no version tags pointing to it is to be treated as a commit onmain
? Or does detachedHEAD
need to be configurable with its own branch configuration? Thoughts @HHobeck?
The business logic is as follows:
and
What if you have two tags on the same commit, which one should you pick? What if the picked tag is not the one you want?
If you have two tags it depends on the one hand on the effective branch configuration and on the other hand what kind of release tags you have.
Following scenarios coming to my mind for the GitFlow/v1 workflow with mode: ContinuousDelivery
:
Please keep in mind that:
Elsewhere in GitVersion, we pick the highest version number available. Wouldn't that make sense in this case as well, @arturcic? In any case it is important to define somehow what the current branch is.
The documentation says:
Detached HEAD
If HEAD is in detached state tag will be
-no-branch-
.Example:
0.0.1--no-branch-.1+4
I have no idea for what this is good for. In my opinion an exception would be better if the current branch is not known.
I think we need to clarify what use cases we have when running gitversion by selecting just a tag commit and what the expected behavior might be.
In the log output from the current ticket it seems to me that you have selected a tag commit which is not part of any branch:
INFO [24-09-18 9:18:19:08] HEAD is detached and points at commit 'bd0483d972605906d5cc1d748c84c90a485d29ad'. .. refs/tags/1.4.1 (bd0483d972605906d5cc1d748c84c90a485d29ad) INFO [24-09-18 9:18:19:08] No local branch pointing at the commit 'bd0483d972605906d5cc1d748c84c90a485d29ad'. Fake branch needs to be created. INFO [24-09-18 9:18:19:09] Fetching remote refs to see if there is a pull request ref
Why would you create a tag on a branch and deleting the branch afterwards without merging the commit. Makes no sense in my opinion.
Why would you create a tag on a branch and deleting the branch afterwards without merging the commit. Makes no sense in my opinion.
On the other hand it might be generally a use case to produce the version number of the tag independent of the branch. Please see following discussion:
https://github.com/GitTools/GitVersion/discussions/4291#discussioncomment-11236502
The author @devorient want to help. Maybe we could agree on a concept.
Prerequisites
GitVersion package
GitVersion.Tool
GitVersion version
6.0.2
Operating system
Linux
What are you seeing?
Related to #2074, #2456, #4015, and #4183; when a GitHub Action with
on: workflow_dispatch
is manually started in the GitHub UI by building a specific tag, GitVersion crashes:To fix all of these bugs and crashes, I believe we need to do as I write in https://github.com/GitTools/GitVersion/discussions/4183#discussioncomment-10484112:
In a Unix terminal, the question "what is the highest tag currently pointing at the current commit" can be answered by the following command:
Something similar should be possible to do with libgit2sharp, I presume.
What is expected?
GitVersion should run on a checked out tag without problems and calculate a version as if it was a tagged commit on
main
.Steps to Reproduce
I assumed a GitHub Actions workflow like this would be able to reproduce the issue consistently, but it unfortunately doesn't:
I've tried to reproduce the problem in this workflow run, but for some reason, it doesn't fail. The main difference is the following log line:
GitVersion then goes on to attempt
git fetch
of the remote, which fails because GitVersion isn't authenticated. As GitVersion already should know that tag1.4.1
points to the commitbd0483d972605906d5cc1d748c84c90a485d29ad
(as can be seen by the log), it should just use1.4.1
as the version number and not attempt any further normalization, Git fetch, or similar.RepositoryFixture Test
No response
Output log or link to your CI build (if appropriate).
No response