huserben / TfsExtensions

Extensions for TFS 2015+ such as custom Widgets (require TFS 2017) and Build Tasks
MIT License
44 stars 22 forks source link

Unable to trigger a Gated build by passing Build.Reason parameter #133

Closed s-h-r-e-y closed 4 years ago

s-h-r-e-y commented 4 years ago

We have a requirement to trigger a Gated chain build with a shelveset (which it should attempt to check-in). The shelveset gets passed correctly through the Build.SourceTfvcShelveset variable. But it doesn't check-in the shelveset. We have tried passing the parameter Build.Reason as CheckInShelveset, but it always come as Manual in the child build.

Any ideas/suggestions?

huserben commented 4 years ago

Hi @s-h-r-e-y

As far as I understand Gated-CheckIns can only be triggered by the system itself and not manually. If you want to set off some "triggered builds" you would need to add a gated check in build that is then triggering other builds and awaiting for them to be finished. However then you will be blocking one build agent for the time while you wait...

Is that what you would like to achieve?

Regarding the Build.Reason parameter, you cannot override anything that is not "Settable at Queue Time", so none of the predefined variables are acutally "overwritable" I think.

s-h-r-e-y commented 4 years ago

Hi @huserben,

Thanks for taking time to reply. We are able to achieve the same functionality using our own PowerShell script (attempt a Gated check-in, (manually) through a script) Some things which are not very clear to me is which parameters does TFS allow to override. Because even though Build.SourceTfvcShelveset is a predefined variable, i can use Trigger Build task to pass this value and the child build does correctly unshelve the passed shelveset. That's why i was hoping that Build.Reason would do the trick too.

huserben commented 4 years ago

Hi

oh I was not aware that this is possible. Sorry for making wrong assumptions. Normally what can be overriden are parameters that are settable at the queue time by the user, so if you trigger a build manually you can select which source version it should take, that's why you can probably set it.

If you share the Powershell script with me I could have a look at it and see how we could make the same behavior with the task. I can't promise that it will work but I would give it at least a look and try to implement something if the effort would not be too big :-)

s-h-r-e-y commented 4 years ago

Hello @huserben,

This is the relevant TFS api call snippet:

$body = @{ "definition" = @{ id = $buildId }; "reason" = $BuildReason; "sourceBranch" = "$ShelvesetNameWithUser"; } $queueBuildUri = $TFSInstanceURL + '/' + $ProjectCollection + '/' + $TeamProject + '/_apis/build/builds?api-version=2.0' $buildresponse = Invoke-RestMethod -Method Post -UseDefaultCredentials -ContentType application/json -Uri $queueBuildUri -Body (ConvertTo-Json -InputObject $body)

Thanks for taking out time to take a look 👍

huserben commented 4 years ago

Hi @s-h-r-e-y

I played a bit around with it and tried to make the task trigger a gated build, but sadly I failed to achieve it.

I currently have not too much time on my hands to do more investigation, shall I just leave the issue open until eventually I might can do more investigation or shall we close it with a "Not supported"?

s-h-r-e-y commented 4 years ago

Hi @huserben,

No worries at all. I'll leave it up to you. You can mark it unsupported or future enhancement or closed.

huserben commented 4 years ago

Ok, as I don't think support will be added in future i'll close it. Thanks for raising the issue.