Unable to set TargetPath in v3.5.3

[stephanjohnson]

I am using GitVersion with Visual Studio Team Services continuous integration. I use the task with Release Management and ensure that my .git folder is copied from the build to the drop location so that GitVersion can correctly identify the versioning information.

Because I loose context between the build and the release management processes, I manually set the target path for GitVersion in Release Management using the /targetpath argument:

/targetpath "$(System.DefaultWorkingDirectory)\$(Release.DefinitionName)\drop"

This results in the following output:

2016-05-17T07:47:37.2150142Z C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\1.99.0\tasks\GitVersion\3.5.1\GitVersion.exe  /output buildserver /nofetch /updateassemblyinfo true /targetpath "C:\a\67de519fa\PROJECT NAME\drop"
2016-05-17T07:47:37.2725041Z INFO [05/17/16 7:47:37:26] Working directory: C:\a\67de519fa\PROJECT NAME\drop
2016-05-17T07:47:37.2745038Z INFO [05/17/16 7:47:37:27] Applicable build agent found: 'VsoAgent'.
2016-05-17T07:47:37.3115046Z INFO [05/17/16 7:47:37:31] Project root is: C:\a\67de519fa\PROJECT NAME\drop
2016-05-17T07:47:37.4175053Z INFO [05/17/16 7:47:37:41] Begin: Loading version variables from disk cache

However, since update 3.5.3 the target path argument seems to be ignored and the resulting output is similar to what I had before I set the target path:

2016-05-18T07:48:36.8076418Z C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\1.99.0\tasks\GitVersion\3.5.3\GitVersion.exe  /output buildserver /nofetch /targetpath "C:\a\79fcd8433\PROJECT NAME\drop"
2016-05-18T07:48:36.8496430Z INFO [05/18/16 7:48:36:84] Working directory: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\1.99.0
2016-05-18T07:48:36.8506431Z INFO [05/18/16 7:48:36:84] Running on Windows.
2016-05-18T07:48:36.8556428Z INFO [05/18/16 7:48:36:85] Applicable build agent found: 'VsoAgent'.
2016-05-18T07:48:36.8876433Z ERROR [05/18/16 7:48:36:88] An unexpected error occurred:
2016-05-18T07:48:36.8886427Z System.IO.DirectoryNotFoundException: Can't find the .git directory in C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\1.99.0
2016-05-18T07:48:36.8886427Z    at GitVersion.GitPreparer.GetDotGitDirectory()
2016-05-18T07:48:36.8886427Z    at GitVersion.ExecuteCore.ExecuteGitVersion(String targetUrl, String dynamicRepositoryLocation, Authentication authentication, String targetBranch, Boolean noFetch, String workingDirectory, String commitId, Config overrideConfig)
2016-05-18T07:48:36.8896435Z    at GitVersion.SpecifiedArgumentRunner.Run(Arguments arguments, IFileSystem fileSystem)
2016-05-18T07:48:36.8896435Z    at GitVersion.Program.VerifyArgumentsAndRun()

While I appreciate the new changes and the fact that they are promptly delivered as updates to the VSTS workflow, I have to change about 30 release management processes to reflect any changes that have happened, and I am unable to get it to work.

I have tried changing /targetpath "C:\a\79fcd8433\PROJECT NAME\drop" to -targetpath "C:\a\79fcd8433\PROJECT NAME\drop" and also /targetpath:"C:\a\79fcd8433\PROJECT NAME\drop". None of them make any difference.

Hope you can point me in the right direction to correct this issue.

I know I can get GitVersion 3.5.1 and ship the EXE with each and every repo that I'm building and putting through my release management process, however this is unnecessary complexity and prevents me from benefitting from any updates that you guys do in the future.

Regards,

Stephan

[stephanjohnson]

I've managed to get it to work:

I set the Update AssemblyInfo files flag on the build task. This produces /updateassemblyinfo true in the resulting execution, however by going over the change log this is no longer the case by default because of #859 getting fixed.

To resolve my problem, I'd have to edit all 30 release management packages with 3 environments each. That's 90 steps to enable the checkbox.

I don't need this checkbox set, since I use it during the build process, not the release management process. At this point in time I don't even have an AssemblyInfo.cs file anymore, just the resulting DLL's.

[asbjornu]

@stephanjohnson This seems related to #867 which is merged and included in the just released version 3.5.4. Can you try that and see if it remedies the problem?

[stephanjohnson]

Hi @asbjornu,
I am using the Visual Studio Online (Team Services) extension, so I am at the mercy of when you guys update the extension. However I will keep an eye on the version number and when it reports 3.5.4 I will revert back.

Thanks

[asbjornu]

@stephanjohnson I see. I hope @pascalberger can help out there as I know nothing about VSTS.

[pascalberger]

@stephanjohnson The update for VSTS should be deployed tomorrow.

I'm sorry for the troubles caused by the extension update. Microsoft has some VSTS enhancements planned (Shared tasks so that changes can be done centralized, and possibility to lock to a certain extension version to have control over deployment process) which should reduce the pain caused by bugs like this.

[stephanjohnson]

Hi @pascalberger,

No worries ;) Lucky I was able to go through the historical logs on my side and the changelog from your side to determine what I can do to work around it.

I'll keep you guys posted as soon as I see he new version arrive on VSTS.

Regards,

Stephan

[asbjornu]

Is 3.5.4 available on VSTS yet? I don't even know how to figure out the answer to that question; that's how clueless I am of VSTS. 😄

[pascalberger]

@stephanjohnson Has this issue been solved and can be closed?

[asbjornu]

I'll close this due to inactivity. If this is still a problem, please reopen @stephanjohnson.