Build from label or changeset and use same version causes error

[JohnHennesey]

In the TFS UI when building from a specific label or changeset entering in either an "L" or "C" as a prefix then the label/changeset is necessary.

For example to build off the label "7.101" I enter in "L7.101" in the source version text box. When calling the child build it blows up with the below error: 2017-09-25T20:12:38.9813483Z { definition: { id: 221 }, sourceBranch: "$/Breeze/Utilities/BuildScripts", requestedFor: { id: "92968178-d553-40d1-9495-8383940fef92"}, sourceVersion: "CL7.101", parameters: "{\"Tst.BranchName\":\"7.1/7.101/Breeze 7.101\", \"Tst.CopyToPostBuildDrop\":\"true\"}"}

(Note the sourceVersion value - it has CL7.101)

It appears the powershell script behind the scenes is prefixing with 'C'. I am in the process of starting a snapshot on the server then upgrade to the latest version of code, hopefully it is fixed. If it isn't fixed yet I don't mind going into the powershell script to modify it to test it out. Where would I find it?

Update : I found where it puts the script while doing the build - it does look like there is some logic around this. I am unable to kick off a new build without either a C or L - the exact comments are "Specify a source version to build. For example, LSelfTest will build label SelfTest. C8 will build Chageset 8." I am using on premise TFS if that makes any difference.

if ($useSameSourceVersionAsBool){
    $sourceVersion = $($env:BUILD_SOURCEVERSION)
    $repositoryType = $($env:BUILD_REPOSITORY_PROVIDER)

    # if we use a TFS Repository, we need to specify a "C" before the changeset...it is usually set by default, except
    # If we use the latest version, the source version will not have a C prepended, so we have to do that manually...
    if (-Not $sourceVersion.StartsWith("C") -and $repositoryType -eq "TfsVersionControl"){
        $sourceVersion = "C$($sourceVersion)"
    }

    Write-Output "Triggered Build will use the same source version: $($sourceVersion)"
    $sourceVersionBody = "sourceVersion: ""$($sourceVersion)"""
}

Thank you, John

[JohnHennesey]

I modified my local version in the agent folder and I am able to get by. I think the line below is what it should look like. If using "TfsVersionControl" and the $sourceVersion type isn't specified assume changeset, otherwise don't touch it.

I still plan to update to the latest version - getting IT to begin a server snapshot takes a little bit. Do you know where the permanent home for this script lives? I would like to update it at the source so it gets distributed among our agents.

    if ($repositoryType -eq "TfsVersionControl"){
        if (-Not $sourceVersion.ToUpper().StartsWith("C") -and -Not $sourceVersion.ToUpper().StartsWith("L")) {
            $sourceVersion = "C$($sourceVersion)"
        }
    }

(I think the right thing to do here is create a branch, modify the code, build, download and test, then submit for approval, right? I'm sorry, I have never used GitHub. I just tried to create a branch and I am not able to - I assume it is because I am not an official contributor to this project.)

[huserben]

Hi @JohnHennesey

thanks a lot for figuring that out, it could be that I never tried it with a Label 😱 I remember there was special code needed for TFS repos and that's exactly the line you found.

However as the PowerShell Script is not used in the newest version it actually needs to be patched in the node.js version where I assume the same problem occurs. But that won't solve your issue, as you currently need the PS Version. If you use an On-Prem TFS you can simply work against the vsix file, what I could offer is to quickly include your changes and package it for you. I don't think there is a possibility to get it to the marketplace in parallel to the node.js version

[huserben]

As I believe we are in different timezones (or just have a different rythm of when to work :D) I will just put the created task pacakge in here in case you can use it, so you don't need to wait for me again. I simply added your code snipped to the powershell task and recreated the package.

Github doesn't allow to upload vsix files, so i renamed it to zip. Simply rename it back to .vsix once you donwloaded it.

However as vsix is actually a zip, you can even extract it and make sure i did the right thing in the powershell script :-) benjhuser.tfs-extensions-build-tasks-1.11.2.zip

[JohnHennesey]

That is fantastic! I had no idea the .vsix is simply a zip - I will do that. Once the dust settles down around here I plan to upgrade (we have lots going on). I plan to wait until the node.js version is updated.

Thank you!

[huserben]

Ok, I already made the code change in the node version, however I want to test it a bit before. I might not manage before the weekend though.

Were you able use the attached package for your builds then? :-)

[JohnHennesey]

I am hoping to get to it today or tomorrow. Thank you for such quick response! Hopefully in another 3 weeks I can upgrade to v2.*. We are on a 3 week sprint cycle and I am proving out an important the new build process this week - need to limit the variables in the picture.

I'll keep you posted.

[huserben]

Ok, just let me know if you need further assitance. I try to write back as soon as I can, however sometimes it might take a day or so due to other responsibilities :-)

[huserben]

Hi @JohnHennesey

I uploaded the version 2.3 of the Task which should include the same fix as you proposed in the PowerShell Script. I tried with building a label and it worked for me.

Shall I close this issue or should we keep it open until you could verify it works as well? Otherwise I can close it for now and we could reopen it when you manage to upgrade and figure out the issue ain't solved.

[JohnHennesey]

I plan to update our TFS on 2017-10-13. I'll keep you posted.

[JohnHennesey]

Just installed it today - ran through a few tests. Looks great - thank you for your help!

[huserben]

Ok super, thanks for the feedback. Then i'll close this issue.