I'm trying to find a release task that I can place inside a Release Pipeline Stage's workflow to intentionally stop the Release.
I have a large provisioning pipeline with 50 tasks per Stage (and 6 Stages). Barring a few exceptions the Stages are identical in Tasks, only differing with variables.
After the 10th task if a variable is true, then I want to stop the Release. This is not a failed Release (so I don't want to mark the Release as failed), it just means after the 10th task there is legitimately nothing more to do.
I see lots of information saying create a condition on an existing Task so that the Task only runs when the condition evaluates to true.
This Microsoft documentation suggests to me that on Tasks 11 to 50 I would need a custom condition that says "only run if variable = true". I might have misunderstood the behaviour and there might be another way to achieve the same result.
Why do I want a Task and not a Condition?
Conditions seem to cater for pre-conditions, not post-conditions scenarios. If it has to be a condition I'd rather say, "stop the release successfully after the 10th task has completed successfully and the variable = XYZ" using a post-condition such as:
eq(variables['RunTasks11To50'], 'True')
This is a pain to do this 40 times for a pre-condition (11th task onwards) and it is also error prone as the condition is not obviously set without drilling into the task (unlike a disabled task which is greyed out).
If there was a "Stop Release" task that allows the Release to legitimately stop then I wouldn't need to add conditions on Tasks 11 to 50.
Alternatively maybe if there was a "Gate" task that allowed the release to pause and require a confirmation to continue that might work too.
My concern is that I'm going to need to write a condition eq(variables['RunTasks11To50'], 'True') on 40 tasks multiplied by 6 stages (6 environments).
What have I considered?
Writing a Powershell task to call the DevOps Rest API to cancel my own Release
Somehow disabling the Tasks 11 to 50 at runtime (again probably requiring a Powershell Task DevOps Rest API call)
Wondering if I'm looking for a complicated answer when there's something obvious and simple I've missed.
Thanks for any advice.
Unfortunately, there is no "Gate" task to stop the release.
Alternatively maybe if there was a "Gate" task that allowed the release to pause and require a confirmation to continue that might work too.
We could set Post-deployment conditions or Pre-deployment conditions to add Approvers.
We recommend that you using condition on Tasks 11 to 50 in the release pipeline and use condition on Stage2 to Stage6 to skip the stage task.
Also, we could add task power shell tp call the REST API to cancel the release.
Related
We are using GitLab and GitLab CI which has a build, test and package step. We have written a script which checks if a user has done some house keeping for the feature they have added. The script returns a 1 or 0 depending on if the house keeping is done. At the moment the script goes in the build step of the GitLab CI, which means the build fails unless the house keeping is done. This is good, as the developer wont be able to merge until the house keeping is done. But, it would be better if the build and tests would continue to run, but the user was simply blocked from completing the merge request. E.g. by adding some automated "approve" step that is approved when the script passes.
Is there an obvious, easy or best way to do this?
Thanks
Set the job to use the builtin .post stage and use needs: []. This will cause the job to (1) run immediately with no delay and (2) will not stop your build/test or any other jobs from starting because it is in the last stage and (3) the failure of the job will still block the merge (provided you have the require pipelines to succeed setting enabled)
housekeeping:
stage: .post # always the last stage in any pipeline
needs: [] # start immediately with no dependencies
script: "..."
# ...
You could have this check as the very last step in the CI, this way everything else would go through and only this would fail.
Another way is marking all the other jobs as when: always instead of only running them when the previous jobs where successful.
Because "reasons", we know that when we use azureml-sdk's HyperDriveStep we expect a number of HyperDrive runs to fail -- normally around 20%. How can we handle this without failing the entire HyperDriveStep (and then all downstream steps)? Below is an example of the pipeline.
I thought there would be an HyperDriveRunConfig param to allow for this, but it doesn't seem to exist. Perhaps this is controlled on the Pipeline itself with the continue_on_step_failure param?
The workaround we're considering is to catch the failed run within our train.py script and manually log the primary_metric as zero.
thanks for your question.
I'm assuming that HyperDriveStep is one of the steps in your Pipeline and that you want the remaining Pipeline steps to continue, when HyperDriveStep fails, is that correct?
Enabling continue_on_step_failure, should allow the rest of the pipeline steps to continue, when any single steps fails.
Additionally, the HyperDrive run consists of multiple child runs, controlled by the HyperDriveConfig. If the first 3 child runs explored by HyperDrive fail (e.g. with user script errors), the system automatically cancels the entire HyperDrive run, in order to avoid further wasting resources.
Are you looking to continue other Pipeline steps when the HyperDriveStep fails? or are you looking to continue other child runs within the HyperDrive run, when the first 3 child runs fail?
Thanks!
I have following azure release pipeline:
Problem is that I need to left left stage to fail sometimes, but at the same time, even if it failed, right stage should still be executed, is that possible?
The only thing I found was 'Trigger even when the selected stages partially succeed' but it does not work if previous stage FAILED.
I need to left left stage to fail sometimes, but at the same time, even if it failed, right stage should still be executed, is that possible?
Yes, it's possible. Please follow below steps and see if it works for you:
First, enable "Trigger even when the selected stages partially succeed" for the right stage as you already did.
Then, enable "Continue on error" for the tasks or the specific task if you know which one would fail in "Control Options". This will force the task to continue even it met errors which makes that stage a partially succeeded one.
At last, you can run the release pipeline and see the right stage will be executed even the tasks in left stage failed.
Hope this would work for you.
I have an Azure Pipelines pipeline defined by a YAML file that compiles, runs some tests, and then publishes test results. It's clearly impossible to run tests without compiling, so the compilation task obviously has the continueOnError: false set. However, I would still like to publish the test results when the tests fail, so I set continueOnError to true under the testing task.
This seemed like it worked, until one of my tests failed. Then, instead of failing the build, Azure just reported a warning. How can I get it to still error the entire build but also execute the remaining tasks?
UPDATE:
Microsoft has added some new documentation since I posted this answer that explains it better than I have:
A given task or job can't unilaterally decide whether the job/stage continues. What it can do is offer a status of succeeded or failed, and downstream tasks/jobs each have a condition computation that lets them decide whether to run or not. The default condition which is effectively "run if we're in a successful state".
Continue on error alters this in a subtle way. It effectively "tricks" all downstream steps/jobs into treating any result as "success" for the purposes of making that decision. Or to put it another way, it says "don't consider the failure of this task when you're making a decision about the condition of the containing structure".
ORIGINAL ANSWER:
I think it's useful to clear up a misunderstanding about exactly what a couple of the YAML properties do (because this got me too). The question asked about a YAML pipeline which the existing answer didn't cover so I thought I'd give an example of that too.
continueOnError determines whether the current task continues if it encounters an error (with a warning), or if it fails straight away. Despite the name being potentially misleading, it does not (directly) determine whether execution continues to subsequent tasks or not.
condition decides whether a task runs or not. By default, if a previous task failed, then this one will not run. You can override this and have tasks run regardless of earlier failures.
Therefore, it is not necessary to use continueOnError if your tests fail, just in order for the Publish Test Results task to run, you can have it run anyway.
I don't know exactly how your pipeline is structured, but hopefully this demonstrates an example:
trigger:
- main
pool:
vmImage: ubuntu-latest
steps:
- script: 'echo "compiling....."; exit 0'
displayName: 'Compile'
- script: 'echo "testing....." ; exit 1' # exit 1" simulates task failure
displayName: 'Run Tests'
condition: succeeded()
- script: 'echo "publishing test results....."'
displayName: 'Publish Results'
condition: succeededOrFailed() # Run task even if previous ones fail
The result is that the overall pipeline is failed:
And we can see the test results are still published in the pipeline breakdown (despite a previous step failing, there is no need here for continueOnError):
You can play around with the exit code in the YAML example to determine which tasks fail. I found the documentation of exactly what can go in the condition field to be a bit poor, but specifically I'd refer you to Conditions, Expressions, and Expressions#Job status check functions.
You can set the Publish test results task's Control options as below.
Then you will get the result as this.
If your compilation task always run successful, you can use the default conditions. If not, I think you can use custom conditions. For example, add a task to create a variable after your comilation task, then use the variable's value as the publish test results conditions, like and(succeeded(), eq(variables['variableName'], 'variableValue'))
You can specify the conditions under which the task or job will run. More detailed information, you can refer to here.
This might seem like a silly thing to say, the final branch in a parallel activity so I'll clarify. It's a parallel activity with three branches each containing a simple create task, on task changed and complete task. The branch containing the task that is last to complete seems to break. So every task works in it's own right, but the last one encounters a problem.
Say the user clicks the final tasks link to open the attached infopath form and submits that. Execution gets to the event handler for that onTaskChanged where a taskCompleted variable gets set to true which will exit the while loop. I've successfully hit a breakpoint on this line so I know that happens. However the final activity in that branch, the completeTask doesn't get hit.
When submit is clicked in the final form, the operation in progess screen says of for quite a while before returning to the workflow status page. The task that was opened and submitted says "Not Started".
I can disable any of the branches to leave only two, but the same problem happens with the last to be completed. Earlier on in the workflow I do essencially the same thing. I have another 3 branch parallel activity with each brach containing a task. This one works correctly which leads me to believe that it might be a problem with having two parallel activites in the same sequential workflow.
I've considered the possibility that it might be a correlation token problem. The token that every task branch uses is unique to that branch and it's owner activity name is est to that of the branch. It stands to reason that if the task complete variable is indeed getting set to true but the while loop isn't being exited, then there's a wire crossing with the variable somewhere. However I'd still have thought that the task status back on the workflow status page would at least say that the task is in progress.
This is a frustrating show stopper of a bug for me. Any thoughts or suggestions would be much appricated so I can investigate them.
my workflow scenario is to reassign task to it's originator after due date of the task expires, by firing a delay activity.
in my workflow I have a parallel replicator which is used to assign(create) different tasks to different users at the same time.Inside replicator I used a listen activity so in the left branch there is a OnTaskChanged activity+...+ completetask1, In the right branch of listenActivity there is a Delay Activity followed by a CompleteTask2 activity and a code activity to reassign task to task originator.I'm sure about the correlation tokens on both completetasks activities.every thing works fine on the left branch but error occurs in the right branch which contains Delay activity-->Completetask activity.
let consider that we have two tasks assigned to 2 users and they have one hour to complete their tasks, but they didn't.so Delay activity fires for both tasks.then in workflow first task will be completed but for the second task it makes error.
I think the problem is with taskid property of the completetask.it doesn't updated with the second task id, so it tries to complete a task which has been completed.