Azure-pipelines-agent: Cancelled builds using task.setvariable still show as success

Created on 2 Aug 2018  ·  15Comments  ·  Source: microsoft/azure-pipelines-agent

Have you tried trouble shooting?

Yes

Agent Version and Platform

2.131.0 / Windows_NT

VSTS Type and Version

VisualStudio.com
What is your account name? Can't provide publicly.

What's not working?

Using the below in a PowerShell script to cancel a build from a task. The task shows as canceled and the build stops, but the build shows as success. This results in any release, with an automatic artifact trigger, to create a new release even though the build was cancelled. the UI also shows the build as successful.

Write-Host "##vso[task.setvariable variable=agent.jobstatus;]canceled"
Write-Host "##vso[task.complete result=Canceled;]DONE"

enhancement stale

All 15 comments

@jasonbert we don't support you cancel your task within a task, cancellation has to start from outside in, like user cancel the build/release from UI or REST api.

@TingluoHuang I assume you meant "cancel your build within a task", you can definitely cancel the task within a task :). Poking around other issues in this GitHub, I noted:

The above links intimate you can do it with the aforementioned VSO tasks. Seems odd that I can set the variable, but it doesn't respect the change? Surely it's logical to have the ability to set the status of a build after it's run? From what I can see, no matter what I set in the variable it doesn't respect it once the build has run. How are you supposed to mark a build as SuccessWithIssues?

@jasonbert I think that's by design.

I wrote a utility called vstsabort https://github.com/lextm/vstsabort and you can use it abort the build as cancelled. I am not sure if SuccessWithIssues can be achieved though.

@lextm thanks for the utility, I will consider it :). My understand is that it just makes a REST callback and cancels the build that way?

I don't think it's unreasonable to have this ability, changing the status of a build from within a task. Primary purpose of DevOps is to automate manual tasks and reduce the need for human intervention. Build definitions should be able to make recover from situations and make decisions.

@jasonbert yes. The script uses your personal access token to cancel the build on server side via a REST API call.

By default, the agent only needs a token to read build definitions and check out the code.

The requirement of an extra user access token (to modify the build status on VSTS server side) can be a very high cost to "have the ability, changing the status of a build from within a task", which unnecessarily increases the complexity/security risks. I believe that's why Microsoft didn't design it that way.

I disagree that having a token with write access is a high cost. I suspect the reason is because of race conditions, potentially created when build agents are running in parallel for the same build :).

This can also cause issues when a definition has Tag sources set to "On Success". We update the version number as one of the build tasks, but if the build is cancelled before that has a chance to run, the commit is tagged with the default generated version.

Cancelling a build from within a build is a bit odd. Just fail it if you want to stop doing work.

@bryanmacfarlane The web interface allows a build to be cancelled manually, so naturally people might want to cancel from within the build itself. Failing a build can create too much noise, when in some cases you just want the build to do nothing after a certain step.

I wrote a blog post a while ago summarizing the different options to abort, and it also showed a case where abort as cancelled is preferred to other options.

so naturally people might want to cancel from within the build itself

It feels like another state to me like aborted. Cancelled implies it was cancelled.

Cancelled is a state of a build, you can know this by asking the question "what state is that build in?" We're in the game of automation, if you can manually do something you should be able to automate it.

I believe there's some ambiguity in the word "canceled" vs "cancelled".

Try using Cancelled.

Write-Host “##vso[task.setvariable variable=agent.jobstatus;]Cancelled”
Write-Host "##vso[task.complete result=Cancelled;]DONE"

I saw different results on TFS 2015 Update 4 when I used "Canceled" vs "Cancelled".

When I used "Canceled", the build was marked as having failed.
When I used "Cancelled", the build was marked as having been canceled.

@icnocop I'm seeing different results when using those spellings, but I am using azure devops and not on-prem. Agent version 2.147.1.

Write-Host "##vso[task.complete result=Cancelled;]DONE" Results in an error:

Unable to process command '##vso[task.complete result=Cancelled;]DONE' successfully. Please reference documentation (http://go.microsoft.com/fwlink/?LinkId=817296) Command doesn't have valid result value. https://github.com/Microsoft/azure-pipelines-tasks/blob/master/docs/authoring/commands.md

The documentation in the link actually shows 'Cancelled' as a valid value, which is strange. Using 'Canceled' will cancel the task as expected.

The documentation for the Agent.JobStatus variable is correct though, using 'Canceled' will stop the job immediately and mark it as a success, while 'Cancelled' will just continue the job like nothing happened.

This issue has had no activity in 180 days. Please comment if it is not actually stale

The only reason i want to cancel is doing a check that cancel triggers outside of working ours which shall not start the stage.Due limitation for stage scheduler which does not support that any trigger filter by schedule. At the end it don't wanna have a failed build, moreover one that should never be triggered. So cancel is the better in favour of failure

Was this page helpful?
0 / 5 - 0 ratings