-
-
Notifications
You must be signed in to change notification settings - Fork 172
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
Support inheritance in version.json config (or limit Update Build Number tasks) #145
Comments
Your scenario is very compelling. While I don't see the failures you see in my VSTS cloud builds, I do have other trouble with all projects trying to set the cloud build number and would rather just pick one to be the one. |
I'm going to try this out over the next few days. |
If you want someone to test some early bits @AArnott, we can try it out in our VSTS builds. |
Great. :) |
@robmen @desmondgc This is shipped in v2.1.6-beta. Please let me know how it works for you. |
Thanks very much, @AArnott - it's working perfectly! I moved the cloudBuild section to a separate version.json file in a shared base project and now I only see a single "Update Build Number" command in the TFS build logs. For reference, my root $/version.json now looks like this: {
"$schema": "https://raw.githubusercontent.com/AArnott/Nerdbank.GitVersioning/master/src/NerdBank.GitVersioning/version.schema.json",
"version": "5.0",
"assemblyVersion": {
"precision": "revision"
},
"publicReleaseRefSpec": [
"^refs/heads/main/development$",
"^refs/heads/main/integration$",
"^refs/heads/main/release$"
]
} ... and I added a new version.json at $/Domain/Common/version.json, where the Domain.Common project is referenced in every solution: {
"$schema": "https://raw.githubusercontent.com/AArnott/Nerdbank.GitVersioning/master/src/NerdBank.GitVersioning/version.schema.json",
"inherit": true,
"cloudBuild": {
"setVersionVariables": true,
"buildNumber": {
"enabled": true
}
}
} |
Fantastic. Thanks for reporting back, @desmondgc. I'll get the feature documented (I missed that in the original PR) and ship a stable versioned package to nuget.org then. |
We are using GitVersioning in a number of solutions (~66 projects total). All assemblies should be versioned the same across the codebase, so the GitVersioning package was installed in each project and we created a version.json in the repo root. We use TFS as our build server so the cloudBuild.buildNumber feature was enabled. As a result, when solutions are built, the log shows that the build number is being updated dozens of times. It seems like this is causing some of our builds to fail intermittently ("Error while copying content to a stream" or "An error occurred while sending the request").
While I'm sure the builds failing is a Microsoft issue, I'd also like to limit the number of "update build number" tasks to keep the logged output clean. One of the projects in this codebase contains core shared business logic that is referenced in every solution. I'd like to enable cloudBuild.buildNumber task in this shared project only but have it inherit the version and other settings from the root project.json file. Unfortunately, when I tried to configure this:
Is there a way to inherit config or otherwise limit the number of "Update Build Number" tasks when cloudBuild output is enabled in the root across multiple projects?
The text was updated successfully, but these errors were encountered: