Setting cloud build number breaks AppVeyor link

[jeffkl]

At the moment, AppVeyor status check report a link that contains the version. After the version is changed (via GitVersioning or any other mechanism), the link is not updated and so when you click on the links in a GitHub pull request you get a 404.

This is a bug in AppVeyor, appveyor/ci#1074, and has been open for almost 2 years. It could be worked around in Nerdbank.GitVersioning by calling a REST API. I'd like to code that up if you'd be open to the contribution. It would essentially do what this workaround does: https://gist.github.com/IlyaFinkelshteyn/def2394231afb7f06dcaeaceda1fb1ae

[AArnott]

That would be fantastic, @jeffkl. Can you write the workaround in C# in our AppVeyor class?

[jeffkl]

Yes I'll code that up, thanks!

[jeffkl]

I have a question about this. When a repository is building in a hosted build environment and GitVersioning is used for every project, does it update the build number N number of times? For AppVeyor that would mean calling AppVeyor UpdateBuild -Version 1.0.0 a lot. That might not matter since they could have a cache and not actually update anything if nothing has changed, but I won't want to call the GitHub web service hundreds of times during a build. I could make something static and it would only be called once per MSBuild.exe which for multi-proc builds would be once per proc count.

Or is there a mechanism I'm missing that only updates the cloud build number once per build?

[tzachshabtay]

@jeffkl I think this is what you're looking for? https://github.com/AArnott/Nerdbank.GitVersioning/blob/master/doc/cloudbuild.md#set-cloud-build-variables-from-just-one-project

[AArnott]

@jeffkl: You should fully code up the process without regard to avoiding duplicates through static fields or whatever. Some repos have different version numbers for different projects, and arrange the build such that the last project to build sets the cloud build number that matters. Of course the link that @tzachshabtay provided contains the best recommendation and what folks should use who want to avoid setting the cloud build number hundreds of times. For most repos though, setting the build number a few times isn't an issue. I've never seen it be an issue myself, except where there were multiple version.json files and the build number kept changing, which is why we now have the inherit property support.

[jeffkl]

It turns out the workaround led me astray. There is no magical GitHub token available to an AppVeyor build that I could find. Users would have to manually generate an API token and place it in their build to get this to work. I don't think that's a very good workaround. The link is only broken until the build completes so we'll have to live with it until AppVeyor fixes it.

[AArnott]

Thanks for looking into it, @jeffkl