Trigger Build extension losing track of successful builds

[patnolan]

Hi,

I have a build definition which has 3 instances of the Trigger Build extension to trigger 3 different builds (see attached image).

The log file (see attached) shows that just before the 3rd build 8696 starts the first two builds completed successfully

"2017-12-22T23:03:22.5597501Z Build 8694 has completed 2017-12-22T23:03:22.5910011Z Build 8695 has completed"

Then just as the 3rd build begins the log file records "2017-12-22T23:03:28.0588207Z Build 8694,8695 has not yet completed".

All three triggered builds have completed successfully, however, the calling build fails.

Am I doing something wrong? Or could this be a bug?

Thanks heaps for your help!

logs_8693.zip

[huserben]

Hi @patnolan

it's strange as it checks for the two previous builds as well, and the actual triggered one is completing successfully. I saw that you enabled "storeInEnvironmentVariable" - do you actually need this for a later step of the build? If you just want to await the build you just triggered you don't have to do that, which means it should as well only check the build you just triggered (so you can remove this flag in all the 3 trigger build tasks as you directly await them as part of the task). Maybe you can give this a try?

I think still there is something fishy as as well with the current setup it should work, but at least to make your build work its worth a shot. I do not have so much free time over the coming days due to holidays, but I could still look into it later :-)

[huserben]

Ah ok I think it is a bug and I think I know why its caused: If we look at the logs of the last trigger build task instance we see: "Following value is already stored in the variable: '8694,8695'" as mentioned, this is because you set to store the variable as part of the previous task. Later on we see that it checks if the builds are already done: "Build 8694,8695 has not yet completed" "Build 8696 has not yet completed"

So somehow it's not properly splitting the comma-separated existing values and instead thinks the build it has to await has the id "8694,8695"

I will look at that as soon as I can. However the above mentioned workaround with not storing it in an environment variable if you don't need would still be valid and would at least not fail your build.

Sorry for the inconvenience

[patnolan]

Hi @huserben,

I have turned off the storeInEnvironmentVariable and that does solve my issue for now.

Thanks very much.

Merry Christmas!

[huserben]

Hi @patnolan

I now uploaded a version that includes a fix for your problem.

Please verify if it is working as expected now and if so close the issue, otherwise let me know so I can investigate further.

Happy holidays and thanks for reporting this issue :-)

[patnolan]

Thanks @huserben I'll test it out.

If you don't mind I have another question for you...

Have you considered creating a Trigger Release extension? I'm using your Trigger Build extension from a Master build definition to order the execution of 3 other build definitions. However, upon successful completion of the Master build, I would like a Master release definition to order the execution of 3 Release definitions.

[huserben]

Ok thanks :-)

Well this is an open request since some time (see https://github.com/huserben/TfsExtensions/issues/9)

I got a code snippet from a custom C# Task that does that, however it needs some time to properly write this in TypeScript and add the correct configuration options etc. which currently is a bit hard to find for me. So to answer your question, yes it's considered and when I find the time I'll implement, but I cannot give you a concrete timeframe when this will happen. I guess it's best to monitor the issue I linked to be informed about updates about this :-)

[huserben]

Hi @patnolan

were you able to test out the newest version and if the issue was fixed? :-)

[patnolan]

Hi @huserben sorry for the slow response. Just got back in front of my pc yesterday.

I can confirm that your change fixed this issue.

Thanks heaps!