Picking up from where I left in the previous note… the other part of the request was to add a conditional step in the associated build definition and update the release definition accordingly. I will elaborate on that here.
Our typical code cycle is something like… code gets committed into a repository, a continuous integration (CI) build kicks off and on successful completion, a continuous deployment release definition kicks off and deploys the build artifact to an environment.
With PR (pull request) builds, however, things can be a little different. The purpose of adding build validation as part of PR is to ensure that the pull request does not cause a CI build to fail. In this case, the feedback is immediate, and even before a reviewer spends time reviewing the PR. Generally, there is no point in reviewing a PR if it is going to break a CI build. BOCTAOE -but of course there are obvious exceptions. Ideally, the developer who submits a PR can fix that and ensure that CI build passes before it is ready for a reviewer.
There were a couple of options to consider enabling PR builds. To make this point clear it is necessary to elaborate on the steps in the build definition.
Step 1: Get code from the repository
Step 2: NuGet restore
Step 3: build a solution
Step 4: test code for vulnerabilities
Step 5: package code
Step 6: upload package as a build artifact
In the case of a PR build, the objective was to only check till step 4. There was no point in wasting time and resources in packaging and uploading the artifact.
Moreover, on the release definition side, there was no requirement to auto-trigger a release in case the build was caused by someone who submitted a pull request.
How do you address those in Azure DevOps?
We use conditions in build definitions. Conditions allow us to trigger a step provided the associated condition is met.
Here is an image of a custom condition in a task that states that the steps will NOT take place if all the previous steps have succeeded (passed) and the build is triggered due to a pull request and the destination branch of the pull request is ‘master’ branch.
At my work, I enabled custom conditions for the last two steps (5 and 6 -package and upload code as build artifact) such that these steps were not executed when the build was triggered due to a pull request and where the target branch of the pull request was ‘master’
And on the release definition side click on pipeline -> artifacts -> continuous deployment trigger -> pull request trigger: disable
As you can see, the Continuous deployment trigger is enabled so that if a build is triggered not due to a pull request, the artifacts associated with that build are deployed.
These changes ensured that when a build was triggered due to a pull request, they did not create artifacts and successful completion of a PR build did not trigger a release to deploy the artifacts (that are non-existent). The concept of PR builds could also be extended such that there is a set of steps in a build definition that are triggered specifically if it is a PR build… maybe extended unit testing of the code or vulnerability testing. In that case, the condition will be something like:
…which would imply that the task would be triggered ONLY if all the previous tasks were successful and the build was triggered due to a pull request and the target branch of the pull request was ‘master’
I hope as a reader you found the two notes useful.
PS: A week after applying these changes, another request came up which is documented at Pull Request Builds in Azure Devops -Part 2
My Devops Journal 