Tasks.json not being updated in build

[JakeGinnivan]

It seems the task.json for the VSTS Task is not being updated properly in the build.

The major, minor, patch fields were empty. Putting this here as I don't have time right now to investigate and track it down. If someone wants to look into it and sort it out that would be awesome 😄

[pascalberger]

The problem is that Update-GitVersionTfsTaskVersion.ps1 is not called in the AfterBuild target of the GitVersionExe project (This line). This due to $(GitVersion_SemVer) not being defined:

Task "Exec" skipped, due to false condition; ('$(GitVersion_SemVer)' != '') was evaluated as ('' != '').

I checked with running build.ps1 locally (and setting Verbosity in build.cake to verbose), which I assume should be the same as on AppVeyor.

I'm on vacation at the moment, but I can have a look at it later tonight.

[pascalberger]

Ah, I just found out that running build.ps1 locally and on AppVeyor are different regarding passing version numbers (See here).

@gep13 Any reason why we are not passing version info if build.ps1 is run locally?

[gep13]

@pascalberger at the end of the day, setting the semantic version of the application is really only important when it is on it's way to getting released, i.e. running on AppVeyor. When running locally it can just be enough to compile and run tests, etc.

[pascalberger]

@gep13 While applying version is not necessary on local builds, I would prefer to have local and CI builds as equal as possible. Especially for debugging issues like this it would make it much more easy to debug (otherwise you need to adopt the Cake script to be equal to the AppVeyor version)

[gep13]

@pascalberger yes, I agree, that we want them to be as close as possible, however...

If we updated the version numbers locally, this will result in changes made to the various assemblyinfo, and json files. How would you want to handle this, as we wouldn't want these files committed as part of any PR's etc. Would these be placed in the .gitignore file? This seems wrong to me.

[pascalberger]

@gep13 Fair point about the changed files. I don't have any better solution at the moment, so probably it's the best way to keep it like it is atm.

[gep13]

@pascalberger I would love to come up with something better, so happy to discuss further. Ignoring those files feels wrong to me though, so unless we revert the changes to those files at the end of the build process.