[AppVeyor] Pull Request Branches Not Building Properly

[gep13]

Is there anything special that I have to do in order to run GitVersion on AppVeyor?

Is it enough to do this:

gitversion.exe /output buildserver /UpdateAssemblyInfo true

In here:

https://github.com/Particular/GitVersion/blob/a4b40aaec5a7bc1f9bb668fed5c4879dc36f8099/GitVersionCore/BuildServers/AppVeyor.cs

There is mention of checking that the agent is set to check out mode. Isn't that a TeamCity thing, or is there something else I need to do in my AppVeyor configuration?

Thanks!

/cc @SimonCropp @distantcam

[gep13]

Also, is there a way to access the individual version numbers, i.e. LegacySemVer if I use /output buildserver?

Thanks

[gep13]

Related question...

When I run GitVersion on AppVeyor, I am seeing this:

https://ci.appveyor.com/project/GaryEwanPark/chocolateygui/build/1.0.10#L41

i.e. a version number of 0.12.0-unstable6 but I would expect to see something like 0.12.0-PullRequest143 since the build was triggered as the result of a Pull Request. But the version number returned suggests that it is being run in the develop branch.

Do you think that this is the side effect of the way AppVeyor is executing the git fetch from GitHub?

@FeodorFitsner any thoughts here? Thanks!

[gep13]

Also @FeodorFitsner

Is there any chance that AppVeyor can support this:

https://github.com/Particular/GitVersion/blob/a4b40aaec5a7bc1f9bb668fed5c4879dc36f8099/GitVersionCore/BuildServers/AppVeyor.cs#L67

In the same way that TeamCity and ContinuaCI do here:

https://github.com/Particular/GitVersion/blob/a4b40aaec5a7bc1f9bb668fed5c4879dc36f8099/GitVersionCore/BuildServers/TeamCity.cs#L33

and here:

https://github.com/Particular/GitVersion/blob/a4b40aaec5a7bc1f9bb668fed5c4879dc36f8099/GitVersionCore/BuildServers/ContinuaCi.cs#L45

[FeodorFitsner]

What is the purpose of GenerateSetParameterMessage method?

[FeodorFitsner]

Re: version number generated by GitVersion - I'm new to GitVersion. What would be a correct way of fetching PR commit in order to have 0.12.0-PullRequest143?

[gep13]

@FeodorFitsner To the best of my knowledge (I am not a core contributor to the project) the GenerateSetParameterMessage is a mechanism to "announce" information from GitVersion to the upstream build system. In the case of TeamCity, which I use at work, this results in Service Messages being sent to TeamCity with other information about the generated Build Number.

GitVersion generates a number of of variables which can then be consumed by other build steps within TeamCity. i.e. once the Version Number of the repo is known, you might have a build step that packages up a nuget package using the generated build number. The service messages allow this information to flow through, and be available to, all the build steps in TeamCity.

For your second question, I will have to defer to other team members.

[distantcam]

Is there anything special that I have to do in order to run GitVersion on AppVeyor?

No, GitVersion will detect when it's running on AppVeyor automatically if it's in buildserver mode.

There is mention of checking that the agent is set to check out mode. Isn't that a TeamCity thing, or is there something else I need to do in my AppVeyor configuration?

Yep, that's a bug. Just ignore that.

Also, is there a way to access the individual version numbers, i.e. LegacySemVer if I use /output buildserver?

Not currently. This is the part that AppVeyor doesn't support.

You could run GitVersion twice, once with buildserver output and once with json output, then parse the json for the variables you require. Why do you want to access those variables?

i.e. a version number of 0.12.0-unstable6 but I would expect to see something like 0.12.0-PullRequest143 since the build was triggered as the result of a Pull Request. But the version number returned suggests that it is being run in the develop branch.

This is how GitVersion does it's numbering. It's not GitHubVersion, and PullRequests are a GitHub thing. This is unrelated to AppVeyor.

What is the purpose of GenerateSetParameterMessage method?

It's a way for GitVersion to set build variables back into the build process. Similar to how TeamCity can change a build parameter during a build. http://confluence.jetbrains.com/display/TCD8/Build+Script+Interaction+with+TeamCity#BuildScriptInteractionwithTeamCity-AddingorChangingaBuildParameter

@FeodorFitsner Are there plans for AppVeyor to support build parameters, and have those parameters changed during the build?

[gep13]

@distantcam quick question, so I can concrete my understanding on this, because I think I must be missing something...

This is how GitVersion does it's numbering. It's not GitHubVersion, and PullRequests are a GitHub thing. This is unrelated to AppVeyor.

In-House, I use GitVersion with a combination of TeamCity and Stash. We use GitFlow, and when we execute a build from:

• a feature branch, GitVersion reports a version number similar to 0.3.0-GSA-.37+1 where GSA-37 is the name of the feature branch.
• a pull request branch, GitVersion reports a version number similar to 0.3.0-PullRequest17 where 17 is the number of the Pull Request in Stash
  • develop branch, GitVersion reports a version number similar to 0.3.0-unstable.60+60
  • master branch, GitVersion reports a version number similar to 0.3.0

Now, all of this makes sense in my head.

However, when AppVeyor runs a build, which is initiated from a Pull Request in GitHub, I would expect it to result in a similar version number to the second bullet point above.

But, as you can see here (ignoring the fact that the build failed):

https://ci.appveyor.com/project/GaryEwanPark/chocolateygui/build/1.0.26

GitVersion is reporting a version number of 0.12.0-unstable6, which suggests it is executing on the develop branch, rather than the Pull Request branch.

Or have I missed something?

You could run GitVersion twice, once with buildserver output and once with json output, then parse the json for the variables you require. Why do you want to access those variables?

The version number reported is the Full Sem Ver one, which is supported by NuGet. I get around this by accessing the LegacySemVer property, and use this when doing nuget pack. Since there aren't any service messages to store all the variables in AppVeyor, I would need to run GitVersion twice, as you suggest.

[gep13]

@FeodorFitsner Are there plans for AppVeyor to support build parameters, and have those parameters changed during the build?

Could we just write the individual variables that GitVersion creates to environment variables, that could then be accessed throughout the remainder of the build?

[robdmoore]

The /exec argument allows you to run an arbitrary executable and that execution will have environment variables set. If it's an MSBuild script then you can use /proj

[gep13]

Right, but that would mean tying any other exe directly to the GitVersion execution. If we wanted to say:

• Run GitVersion
• Go over here and do something
• Then go over there and do something else
• Then use the variables created by GitVersion, we wouldn't have access to them

I was thinking that, in the absence of doing something like this for TeamCity, we could just write out each variable that GitVersion creates to an Environment Variable, so that during the execution of the AppVeyor build, all those variables are available.

[distantcam]

GitVersion is reporting a version number of 0.12.0-unstable6, which suggests it is executing on the develop branch, rather than the Pull Request branch.

Ah, I see now.

https://github.com/chocolatey/ChocolateyGUI/blob/009b542eefdfdc7ca705aa9bb93a9d212afb7b92/BuildScripts/default.ps1#L76

You didn't run GitVersion with the /output buildserver flag. AppVeyor doesn't get all the branches of a repo by default, so GitVersion will do that so it can determine what branch is being built, and the correct branch name, but only when it's running in buildserver mode.

Also, once this is done once during the build, subsequent gitversion calls will have the correct information, so make sure to call /output buildserver first, then any other gitversion calls.

The version number reported is the Full Sem Ver one, which is supported by NuGet. I get around this by accessing the LegacySemVer property, and use this when doing nuget pack. Since there aren't any service messages to store all the variables in AppVeyor, I would need to run GitVersion twice, as you suggest.

If you're were using MSBuild you could have used our MSBuild tasks, but we currently don't have a nice solution for PSake. Feel like contributing a PR?

Could we just write the individual variables that GitVersion creates to environment variables, that could then be accessed throughout the remainder of the build?

That's certainly possible.

[gep13]

Ah, ok, now everything makes sense :-)

I have a long list of things on my to do list, but I will add a PR for psake onto the list. For now, I may do a simpler PR to write out GitVersion variables to Environment Variables so that AppVeyor builds can use them, assuming that @FeodorFitsner isn't going to come back with another mechanism to write those values to.

Thanks for all your help!

Will close issue once I have tested the changes to psake build script.

[gep13]

@distantcam I have updated the build script line that you mentioned to run /output buildserver and although I am seeing a change in behaviour, i.e. the build number in AppVeyor being updated, it is still showing as it coming from the develop branch, rather than from Pull Request branch.

https://ci.appveyor.com/project/GaryEwanPark/chocolateygui/build/1.0.27

Any thoughts?

Thanks!