Skip to content
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

Why is the Build number overwritten in Azure Dev Ops #1457

Closed
kirkone opened this issue Aug 21, 2018 · 10 comments
Closed

Why is the Build number overwritten in Azure Dev Ops #1457

kirkone opened this issue Aug 21, 2018 · 10 comments
Labels

Comments

@kirkone
Copy link
Contributor

kirkone commented Aug 21, 2018

Hi,

I am using the VSTS task to get my nuget packages versioned on build in VSTS ans I was wondering why the "BUILD_BUILDNUMBER" environment variable is being overwritten completely when there is no GitVersion variable in it. I can not see the benefit of this behavior. Did I miss something?

It would be nice to have a name for a build while using GitVersion.

I think here should be a slightly different logic:

if (buildNum == newBuildNum)

Thank you for your help.
KirK

@kirkone
Copy link
Contributor Author

kirkone commented Dec 4, 2018

@JakeGinnivan I know it is a long time ago, but what was the intention behind this change?
I found this commit:
e98f68b
but there I can not see why this change had be made.

If someone want his build number to be replaced I think the better solution would be to set his build number to something like $(GITVERSION_NuGetVersionV2)

Did I miss something here?

Best regards
KirK

@kirkone kirkone changed the title Why is the Build number overwritten in VSTS Why is the Build number overwritten in Azure Dev Ops Dec 4, 2018
@paule96
Copy link

paule96 commented Mar 25, 2019

any updates @JakeGinnivan?

@JakeGinnivan
Copy link
Contributor

Don't remember really, but a wild guess would be that we couldn't detect we were in VSTS, or there were restrictions on updates. I see no reason to change

@kirkone
Copy link
Contributor Author

kirkone commented Mar 28, 2019

hi,
there are cases where you don not need the GitVersion string in the name of the build number. I would even claim it's more the exception to have that. The problem is, that changing the BUILD_BUILDNUMBER variable also overrides the name of the build itself. This is not a good behavior that a random task renames the build even it has nothing to do with it.

Maybe for better compatibility it is an option to have an parameter like --skipbuildnumber or something equal.
I looked into it if I can provide an PR but I did not find the point where to add such a thing.

I hope this explains a bit more why I opened this issue.

@rodchenkov
Copy link

I have the same problem, any update on this?

@kirkone
Copy link
Contributor Author

kirkone commented Aug 9, 2019

@rodchenkov I opend a PR #1770 for this. We will see how this will come out.

@roryprimrose
Copy link

This probably should be an option to set on the task in the pipeline. Some people won't want the build number to be updated, others will, others will set the build number to a GitVersion variable for which a substitution could happen.

I previously set the BuildNumber to $(GitVersion_NuGetVersionV2). The thing I didn't like about that is the build numbers were meaningless if the build failed before the substitution of the build number happened. Off the top of my head I can't remember if the substitution even happened or whether the Task itself just went over the top of my build number variable hack.

As I prefer a different GitVersion variable to be used in my build numbers, I just overwrite what GitVersion uses to overwrite whatever is defined in the pipeline definition.

@stale
Copy link

stale bot commented Jan 20, 2020

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Jan 20, 2020
@arturcic arturcic removed the stale label Jan 20, 2020
@stale
Copy link

stale bot commented Apr 19, 2020

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Apr 19, 2020
@kirkone
Copy link
Contributor Author

kirkone commented May 10, 2020

This is resolved in #1770 , so I will close this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants