A certain task generates a ##[warning] and has a warning status.
It causes the final status of stage to be an orange exclamation mark.
I want to suppress this so that the stage will show as succeeded (green check).
Is there a way to achieve this?
Ive looked at the options at the task itself, but it only has ContinueOnError
*Edit:
Im talking about the Azure App Configuration Extension.
I've even delved into the path of updating the Build Result via REST API
but to unfortunaly, the PATH method doesn't seem to update the build result.
Update from OP
It's a known limitation/bug of task:
Azure DevOps Extension: Azure AppConfiguration - Partial Complete
Currently, by default the build result is "Failed" if anything failed to compile/build, "Partially Succeeded" if there are any unit test failures,ContinueOnError checked, and "Succeeded" otherwise.
It causes the final status of stage to be an orange exclamation mark.
According to your description, that task showing as "Partially succeeded" may due to you checked "Continue on error" option.
Continue on error (partially successful)
Select this option if you want subsequent tasks in the same job to
possibly run even if this task fails. The build or deployment will be
no better than partially successful. Whether subsequent tasks run
depends on the Run this task setting.
Please refer to this document for more info: Task control options
Related
In my pipeline I have a task (among others) that either succeeds or succeeds with issues, controlled by:
if (-Not $packagesAreUpToDate) {Write-Host "##vso[task.complete result=SucceededWithIssues;]"}
This task makes the entire job (containing other tasks) have the status "warning", which is desired.
The issue is when observing the commit history, where the pipeline appears as if they have failed (when they should have the status "Warning" or something similar).
Is there a way to fix this, or is it a bug or feature which has not yet been added by Azure DevOps?
Our structure for a release in azure devops is to
deploy our app to our DEV environment.
Kick off my Selenium (Visual Studio) tests against that environment.
If passes, moves to our TEST environment.
If fails/hard stop.
We want to add new piece/functionality, starts same as above, Except instead of hard stop. 5) if default step fails, continue to next step. 6) New detail testing starts (turns on screen recorder)
The new detailed step has 'Agent Job' settings/parameters, I have the section "Run this job", set to "Only when previous job has failed".
My results have been, that if the previous/default/basic testing passed, the detailed step is skipped. As expected.
But if the previous step fails....the following new detailed step does not kick off.
Is it possible because the step is set up that if it fails hard stop and does not even evaluate the next step?
Or is it because the previous step says 'partially succeeded'. is this basically seen not as a failure?
Yes, this is correct. Because failed is equivalent of eq(variables['Agent.JobStatus'], 'Failed') status. But partially succeeded is eq(variables['Agent.JobStatus'], 'SucceededWithIssues').
Please check here.
You may try custom conditions like :
in(variables['Agent.JobStatus'], 'Failed', 'SucceededWithIssues')
As an addition to the solution, a piece I missed was on the 'detailed' job, the 'Trigger even when the selected stages partially succeed', also needed to be checked, as well as the solution for the same step above.
I want to update a Pipeline with the Definitions - Update REST API call.
That works fine, but when I want to add a custom task (self made build pipeline task extension) then I struggeling to find the correct task reference id:
Invoke-RestMethod : {"$id":"1","innerException":null,"message":"The pipeline is not valid. A task is missing. The pipeline references a task called '7f1fe94f-b811-4ba1-9d6a-b6c27de758d7'. This
usually indicates the task isn't installed, and you may be able to install it from the Marketplace: https://marketplace.visualstudio.com. (Task version 1.*, job 'Job_1', step ''.),Job Job_1: Step
has an invalid task definition reference. A valid task definition reference must specify either an ID or a name and a version specification with a major version
specified.","typeName":"Microsoft.TeamFoundation.DistributedTask.Pipelines.PipelineValidationException,
Microsoft.TeamFoundation.DistributedTask.WebApi","typeKey":"PipelineValidationException","errorCode":0,"eventId":3000}
I check out the registrationId of my custom task with the Installed Extensions - List REST API call. But it is not the correct one. (7f1fe94f-b811-4ba1-9d6a-b6c27de758d7)
I also add the custom task manually to a pipeline and read out the correct task refernce id with the Definitions - Get REST API call. I could find the id in:
$pipeline.process.phases.steps.task.id -> 2c7efb3e-3267-4ac6-addc-86e88a6dab34
But how can I read out this id without adding the custom task manually?
This id is obviously dynamic and changes everytime when the custom task get installed, so there must be a way to get this refernce.
The task id has not changed every time when the custom task gets installed, but he existed in task.json of the task:
{
"id": "2f159376-f4dk-4311-a49c-392f9d534113",
"name": "TaskName",
"friendlyName": "Task Name",
Another option is to use this api:
https://dev.azure.com/{organiztion}/_apis/distributedtask/tasks
You will get a long list of all the tasks, search your task and you will see the id.
We have a scheduled release in Octopus that deploys the last known good release to Prod back to Prod.
However this has started failing because the artifact has fallen out of our retention policy - this we can fix by altering the retention policy.
The real issue is that when it failed no notifications were sent to the team because artifact collection happens before even the first step.
I have tested this with a dummy release that just has a single basic step and then a Slack Notification step for when it fails. However, we never get to the first step - let alone the slack step.
How can i hook on to this failure so that we know about these issues in future.
You have to follow below steps to achieve the same
Step 1) Add Email Template step # First : to inform that Build is triggered
There is a setting in that called : Start Trigger set it to Run in parallel with the previous step so email will be triggered while your artifacts are downloading
Step 2) Add Email Template step # Last : to inform that build failed
Just change the setting Run Condition set it to : Failure: only run when a previous step failed
so when your deployment get fail, It will notify the same. You can add the cause of failure in email body using inbuilt variables also.
I'm running a project configuration using powershell/psake and I'm using the TeamCity powershell module (https://github.com/JamesKovacs/psake-contrib/wiki/teamcity.psm1) yet TeamCity only shows the configuration as "Running"
However, the build log clearly displays all of the service messages:
[15:41:34]WARNING: Some imported command names include unapproved verbs which might make
[15:41:34]them less discoverable. Use the Verbose parameter for more detail or type
[15:41:34]Get-Verb to see the list of approved verbs.
[15:41:34]##teamcity[progessMessage 'Running task Clean']
[15:41:34]Executing Clean
[15:41:34]running the build
[15:41:34]##teamcity[progessMessage 'Running task Build']
[15:41:34]Executing Build
Am I wrong to thing these should be showing up in the project status instead of just "Running"?
It is typo in generated message. I just created pull request with fix. https://github.com/JamesKovacs/psake-contrib/pull/1