-
Notifications
You must be signed in to change notification settings - Fork 654
DynamicRepo - NextVersion.txt file when no /target branch arg #351
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Let's explain how this works. You have a repository with a default branch. If you follow GitFlow, you probably have set the default branch to develop. If you haven't, you are probably on master. From now on, I will call the default branch default. When you clone a dynamic repository, it checks the default branch (you can change that in the server settings, for example in GitHub). If you have pushed NextVersion.txt to the develop branch, but your default branch is master, it cannot find NextVersion.txt thus it will be ignored. Please make sure that the NextVersion.txt is also available on the default branch of your repository. Otherwise it will only work when you specify the branch on which you committed the NextVersion.txt file. As an additional note: adding NextVersion.txt to the master branch doesn't make much sense. I use that feature only to specify the next version on the develop branch so I can create 2.0.0-unstable123 for a repository that is on 1.2.0 on the master branch. |
@GeertvanHorrik my default branch is master. It has a NextVersion.txt file. So I can't see that I have done anything wrong there. If no one else can replicate this I will happily assume user error. However the code you showed me here https://github.com/ParticularLabs/GitVersion/blob/ca002ed570b03f2f3a610523ab79adf34848fdc1/GitVersionExe/GitPreparer.cs#L69 seems to only do the checkout of nextversion.txt if there is a targetbranch arg present - and that is what i am seeing when testing. |
No, if you read the code correctly, it does this:
Can you write a failing unit test? Then I am willing to look into this. |
Hmm, I am always willing to accept my own fallibility. But, I'm reading this:
Irrespective of what I am reading, the issue was raised off the back of actually running GitVersion.exe locally - but I appreciate your caution - no one likes to have there time wasted. There doesn't appear to be any existing test coverage for this otherwise you could just point to the existing test and tell me to run it - nevermind - I will have a go at creating one. In order to carry out the unit test, i'll need the ability to commit a NextVersion.txt file to the local repo used for the unit test. I'll have to get familiar with libgit2sharp before I can do that - I'll work on that as soon as I can. If anyone knows of an existing function in the code base that commits a file to a Repo - i would be greatful if they could point me to that. Cheers |
You are right, I missed the argument check at the top. I think it can be removed, let me double check. |
Thanks @GeertvanHorrik - glad we are on the same page :) I still think a test for regression purposes would still be handy as the NextVersion.txt file is a pretty important feature of GitVersion - but if you don't have time for that I can look into that as it will give me an excuse to get more familiar with the repo as well as libgit2sharp! |
btw. I do recommend to always pass in the branch name since you should never assume the default branch name of a repository. But will fix this anyway. |
GitPreparerTests.WorksCorrectlyWithRemoteRepository is the test covering this. We have a bunch of extension methods on the As for NextVersion.txt this is being completely replaced by GitVersionConfig.yaml. So Whatever you do for NextVersion.txt please add support for GitVersionConfig.yaml at the same time. v3 is dropping NextVersion.txt and only using the config file |
@JakeGinnivan - yep I found that test and those extension methods. I couldn't see anything that commits an actual file - but leave that to me, I only briefly looked at this stage. Thanks for letting me know about the yaml file I wasn't aware of that! |
The first fix is easy:
Will look into GitVersionConfig.yaml support after that. |
@dazinator wondering if you had time to create a wiki page for the dynamic repositories feature in general. I think it would be handy to include tips on how to get the currently building branch names from different CI environments. |
@JakeGinnivan - nope I have not yet created a wiki page for this feature, but I'll happily give that a shot! I have been looking at the existing page here: https://github.com/ParticularLabs/GitVersion/wiki/Command-Line-Tool which does already describe these arguments, but I don't think there is anywhere that explains this particular feature in detail, and how, for example, it enables CI's to work that don't automatically checkout the repo - for example Team City builds that are set to "checkout on agent". Are you thinking having some documentation page per CI system would be the way to go because I like that idea. |
I was thinking have a Dynamic Respositories wiki page. We can link it from the command line args page and also the FAQ. The info per CI system would be more how to get the branch name to pass to the argument so GitVersion calculates for the correct branch (otherwise it will always calculate master version even if building something else). |
@JakeGinnivan - Ah Ok I Get ya. I get the impression I may not understand the full implications of this feature just because my Git skills are weak. For example would it be common to have an scenario where you are building your repo - but you want the version number to be calculated from another repo or another branch? Because if that scenario is common in the Git world, then I can see how this feature might also enable that - I didn't want to speculate on this so the wiki page doesn't mention anything like this at present. |
I think the /b should nearly be made mandatory, one may never rely on the default branch. |
I don't think this would be common. This is mainly for build servers who do not check out a proper git repo. Good work on the wiki page. I think we should say to always specify /b with note about the fallback. Nice work Sent from my Windows Phone From: Darrellmailto:[email protected] @JakeGinnivanhttps://github.com/JakeGinnivan - Ah Ok I Get ya. I get the impression I may not understand the full implications of this feature just because my Git skills are weak. For example would it be common to have an scenario where you are building your repo - but you want the version number to be calculated from another repo or another branch? Because if that scenario is common in the Git world, then I can see how this feature might also enable that - I didn't want to speculate on this so the wiki page doesn't mention anything like this at present. — |
Ok - I have made those changes that you both suggested. Feel free to make any further tweaks. |
Going to close this. See #367 for the enforcing the branch |
When testing the new dynamic repo functionality (thanks for the new feature by the way!), I noticed that the NextVersion.txt file in my repo was not being honoured and therefore my attempts to bump the version number using that file were not working.
To replicate,
Note that the version number GitVersion outputs won't be bumped as per the text file.
I believe if you also pass in an -targetbranch arg to GitVersion then it works but that's an assumption from reading the code not any actual testing.
The text was updated successfully, but these errors were encountered: