Azure Devops 依次运行两个版本

Question

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?

Answer 1

Functionally the two build may not always be the same.

Lets say you have the below example. Capital letters are commits and lower-case letters are potential commits.

  e e'
 /   \
|  |   D
C  |   B 
 \ |  /
   A

This shows, two branches coming off of the A commit (master branch). Each feature branch had a PR created for each one. One branch has a build on the e commit and the other branch had a build on the e' commit. Azure devops cannot be sure which PR will be merged first.

Once you merge both of the PR's you will end up with a new commit in master that has not been previously built. This is described here

   F
   E \
 / |   D
C  |   B 
 \ |  /
   A

If you want to eliminate the need for your build on master, you can set the build expiration to Immediately when branch name is updated

Answer 2

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: