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.
In some cases, the DevOps team may need to checkout multiple github repositories in the current working directory of the pipeline. By default the pipeline will download the code of the repository where it belongs.
The below pipeline will download a github repository based on a parameter that user provides. In order to accomplish that you will need a service connection with your github account/organization.
Then using the below pipeline you can download a repository with a specific branch by providing the repository name.
Developers often have a lot of repositories stored on their local machines. These repositories get updated from other developers and they stay outdated. In many cases developers forget to fetch and pull the latest changes on those repositories and when they commit code, the IDE will notify of the new changes. When this is the case, the commit will get an non explanatory message as the latest of the commit and you will have to navigate on the actual commit to verify the changes and commit message.
Merge branch test/v3.0.0 of https://github.com/org/repository
In order to resolve this issue, you can create a powershell script that can automatically fetch the latest changes of your local repositories. You will need to change your repositories base location.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As you can see from the output below this script will go and fetch the latest changes on the repositories that have been updated.
You can also create a cron job or an automated windows task in order to run this job automatically on computer startup or on your work schedule start. For example
On task scheduler press create task
and select your triggers (when this task will run) along with the action. This will be the run of the powershell script. On the argument you must specify the -File location (where you stored your powershell script).
There are multiple ways to define your continuous integration trigger on a pipeline depending on your needs. One common approach is to trigger a build whenever a new merge or push is done on your branch.
For example with the below notation you could trigger a new build every time a new push is merged on the uat branch.
Another approach could be the pull request. Every time a new pull request is created for a specific branch your build could be initiated. In order to accomplish that you should use the pr keyword.
The below example will trigger when a new pull request is created and the merge destination is main branch. This approach could help you identify if the code of a specific feature/branch actually builds and can be merged on your main branch.
Another approach is the tags functionality. You could run a build only if a specific tag is pushed along with the commit.
The below example will only build when the tag release.* is pushed on the branch on which the pipeline is located.
Some tags that could trigger my build are: release.v1 , release.master, release.v2
In order to push a tag on your branch using cmd you should