We have Azure Devops setup. Right now our Project will Build Twice.
Once during Pull Request Checkin in the YAML file, and another due to Build Settings (picture below).
This triggers two builds, and causes our build time to double. Our Devops team mentioned this is regular practice. Why doesn't Azure Devops just trigger one build, and or is it safer practice with two builds?
Why doesn't Azure Devops just trigger one build, and or is it safer practice with two builds?
As far as I know, this is the expected workflow of Azure Devops.
due to Build Settings
This is the Pull Request trigger.
This trigger occurs in the process of Pull Request, the PR trigger is meant to run whenever a PR is created.
This trigger is equivalent to a verification step, the file is not really committed to the target branch(Pre-merged to Targer Branch).
You can check the results of the build to determine whether the source branch code is valid.
For example:
If the Pull Request trigger fails, you can reject the pull request. It does not affect the target branch, the target branch remains in the original state
Pull Request Checkin in the YAML file
This could be the CI trigger.
This trigger will happen when the pull request is completed.
In this case, the target branch has changed. The change of the target branch triggers the CI trigger. This can double check whether the code is valid.
Summary of workflow:
Create Pull Request -> Pull Request Trigger(Pre-merged and firest check)->Complete Pull Request -> CI trigger (Complete the branch merge and second check).
By the way, if you want to exclude some files so that they do not trigger the Pull Request Trigger, you can add a path filter.
For example: