[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. |
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: