[ISSUE]: GitVersion crashes in GitHub Actions when an action is dispatched on a tag #4212
Comments
|
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).. |
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? |
@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
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 |
The business logic is as follows: and
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
Please keep in mind that:
The documentation says:
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:
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: The author @devorient want to help. Maybe we could agree on a concept. |
@asbjornu: Can you help with the concept? |
|
@HHobeck, I think the following question must be answered before we can proceed:
I highly doubt everyone wants the same behavior for detached treat-detached-head-as: mainThis means detached |
I'm not sure if it's good to introduce such a static value. To me, it doesn't make sense if e.g. you have a commit on a feature branch that was checked out in a detached state and is treated as if it were in the main branch (even I have reasonable doubts that the algorithm can calculate the versions in a meaningfull way). I think we need to have a discussion based on following scenarios: The user has:
Where the commit is based:
And the commit:
In my opinion we have twelve scenarios with maybe different outcomes!! |
|
@HHobeck, thank you for outlining the different scenarios. Indeed, a simple property won't cover all of these scenarios. But I think as a default, it might work if we also allow for runtime overrides. GitVersion already supports (although not fully) the |
|
I like the idea to use the environment variable Git_Branch locally as well to give gitversion a hint about the branch to use. But I would say the following constraint should be ensured:
What do you think? |
|
I like the idea of using Git_Branch for this, this also allows for external logic to be applied to cover corner cases.
|
|
Actually we have already an argument to set the target branch locally: gitversion -b master -nocacheI have tested it and it works quite well. Please notice that the git preparer uses the agent specific target branch and as a fallback the target branch provided by arguments: |
|
I'm at a point where I'm not sure what we are discussing here. In my opinion GitVersion works well with detached head scenarios. All related issues are probably issues in the normalization process. That means we need just to ensure that the outcome is the same for each build agents.
In my opinion the assumption that GitVersion needs to just use the tag without doing a normalization is wrong. First example: Let's say you have a tag v0.2.0 as following: running GitVersion with
Second example: Let's say you have a tag v0.2.0 on a commit which is not part of any branch (because it was reverted): running GitVersion with
Does this make sense? |
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_dispatchis 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 #4183 (reply in thread):
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 fetchof the remote, which fails because GitVersion isn't authenticated. As GitVersion already should know that tag1.4.1points to the commitbd0483d972605906d5cc1d748c84c90a485d29ad(as can be seen by the log), it should just use1.4.1as 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
The text was updated successfully, but these errors were encountered: