When your pipeline fails on Azure DevOps and the source code is gathered from GitHub (using a service connection) you will notice a failure icon on the repository because the status of the run from Azure DevOps is reported to GitHub. This is the normal behavior and we want it to work like that.
Lets take as example the below run.
The failure will be visible on the github along with the particular commit.
However sometimes we need to allow tasks fail without reporting a failure state on GitHub. You can do that by using continueOnError keyword. With this functionality you instruct the DevOps platform to allow failure for a particular task or job without stopping the pipeline.
- job: job1
- script: this script will fail
displayName: task 1
- task: PowerShell@2
displayName: task 2
Write-Host "Hello World"
This will result on a warning state for your pipeline on Azure DevOps.
This means that the pipeline has been executed successfully but some steps have failed.
Nevertheless the state on GitHub will be success as the pipeline is not in a failed state on Azure DevOps.
When you try to push a nuget package from a DevOps pipeline on Artifacts feed you may face the below error.
##[error]Error: An unexpected error occurred while trying to push the package with VstsNuGetPush.exe. Exit code(1) and error(Error:
Microsoft.VisualStudio.Services.Common.VssServiceException: User 'xxx' lacks permission to complete this action. You need to have 'ReadPackages'
This error could be resolved by editing the settings of the feed.
In more detail under permissions you can find which users or service account can perform actions based on their role.
By default I could locate the
Project Collection Build Service (Organization) with the Contributor permissions but did not work. As a solution I removed that and added
"Project Name" Build Service (Organization). This is the build service for the project on which I have created the pipeline specifically.
The below code can be used as a starter entry point for your DevOps pipelines. It is designed with best practices in mind with stages and jobs in order to isolate different functionalities and make it modular. You can include more stages,jobs,tasks by copy and pasting the code.
- stage: stage1
displayName: display name for your stage
- job: job1
displayName: display name for job1
- script: echo job1.task1
displayName: running job1.task1
- job: job2
displayName: display name for job2
- script: echo job2.task1
displayName: running job2.task1
The result is shown below