Task Result is not set properly when Task has an Error

[rfennell]

Can I check my understanding of how your trigger build task should function when the triggered build fails?

I am running on VSTS with Version 2.4.2 of your task.

I have added a Trigger Build task to a release, as a test the build triggered is set to fails i.e. it contains a single PowerShell task with the inline script 'write-error "this will fail the build'.

• If run the build directly on the VS2017 hosted agent it fails.
• If I trigger the build via the release (all on the VS2017 hosted agent) using your task, with the task set to wait for completion, the build is triggered and fails as expected (if I check in the VSTS builds hub), but the release continues as if there has been no error, seeing the trigger build task as having succeeded.

The release logs are as follows

[debug]buildDefinition=Validate-BuildThatFails

[debug]ignoreSslCertificateErrors=false

[debug]queueBuildForUserThatTriggeredBuild=true

[debug]useSameSourceVersion=false

[debug]useSameBranch=true

[debug]branchToUse=null

[debug]waitForQueuedBuildsToFinish=true

[debug]waitForQueuedBuildsToFinishRefreshTime=60

[debug]failTaskIfBuildsNotSuccessful=true

[debug]downloadBuildArtifacts=false

[debug]dropDirectory=C:\BuildAgent_work

[debug]storeInEnvironmentVariable=false

[debug]demands=null

[debug]queueid=null

[debug]buildParameters=null

[debug]authenticationMethod=OAuth Token

[debug]username=null

[debug]password=null

[debug]enableBuildInQueueCondition=false

[debug]includeCurrentBuildDefinition=true

[debug]blockingBuildsList=null

[debug]dependentOnSuccessfulBuildCondition=false

[debug]dependentBuildsList=null

[debug]dependentOnFailedBuildCondition=false

[debug]dependentFailingBuildsList=null

Using current Team Project Url Path to Server: https://XXXXXl.visualstudio.com/TeamProject Trying to fetch authentication token from system... Using OAuth Access Token Build shall be triggered for same user that triggered current build: undefined Using same branch as source version: undefined Queue new Build for definition Validate-BuildThatFails Queued new Build for definition Validate-BuildThatFails: https://XXXXXl.visualstudio.com/TeamProject/_build/index?buildId=1735 Will wait for queued build to be finished - Refresh time is set to 60 seconds Build 1735 has not yet completed Sleeping for 60 seconds... Build 1735 has not yet completed Sleeping for 60 seconds... Build 1735 has completed

[debug]task result: Succeeded

[debug]Processed: ##vso[task.complete result=Succeeded;]Build 1735 was not successful - failing task.

The ##[debug]task result: Succeeded seems at odds with the REST call for the build status once the build has completed which shows.

.... "id":1735, "buildNumber":"1.0.17335.2", "status":"completed", "result":"failed" .....

I am assuming I am just missing something obvious, or misunderstood how the task works. Do I have a parameter on the Trigger Build task wrong or do I need to make a check on an extra check on some output variable?

[huserben]

Hi @rfennell

thanks for your feedback. Your configuration looks correct, there seems to be an issue when checking the result of the awaited build however. I was able to reproduce a similar problem in my environment.

Something seems to be strange, as you can clearly see int he log that it is detecting that the build failed and it is trying to fail the task: "Build 1735 was not successful - failing task." Seems like it "fails to fail the task"...

I will look into that and let you know once i found a solution and updated the Task.

[rfennell]

Thanks for the quick response, I will keep an eye open for future releases.

FYI: Usually happy to help test anything, but I will be going off line for a few weeks from Monday, so apologises in advance for my silence. I know it can be irritating on my OSS projects when an issue is raised and the person who raises it is unresponsive to follow up questions.

So feel free to close this issue when you are happy its sorted

[huserben]

No problem, thanks for raising the issue and help improve the task :-)

Thanks for this announcement as well, I think i'll look into it tomorrow, so if you have time over the weekend there might be a new version already.

I suspect there is some timing issue related to the async execution of the method that should fail the task. In the logs you can see that the task-result is set to succeeded before the line is printed that says that it actually should fail. I will investigate tomorrow into this and if this really is the problem it should be a simple fix.

[huserben]

Hi @rfennell I know updated the Task to version 2.4.3 which should fix the issue that the result is set to Succesful even though the task internally ran into an error. In case you're still around and could verifiy it please let me know if it's working as expected or not.

[rfennell]

Tested it and it now behaves as expected, thanks for the quick fix