CODEWITHSUNDEEP
azureazure-devopsazure-pipelinesazure-pipelines-build-task
DrGriff
DrGriff

Reputation: 4906

Azure DevOps Pipeline build triggering unexpectedly

Updated 26-Feb-2020

In our Project, I have a pipeline "MyPipeline" which restores the NuGet packages, builds the solutions and runs the tests.

On the master branch, I have a policy which does things like add code reviewers, and it has a "build validation" step which executes "MyPipeline". All well and good.

However, I created another branch from Master called NewBranch and synced (pushed) this up to Azure. After doing some minor changes in Visual Studio, I did a merge from master, committed and sync'd to Azure.

I was a bit surprised then to see "MyPipeline" executing. It seems to have been triggered when I pushed my changes to NewBranch to Azure. I don't have a branch policy on "NewBranch". The trigger in the YAML file is:

trigger:
- master

What kicked this off? I'll soon burn through my free agent minutes if this continues...

Update 26-Feb-2020

As per the comments below:

The history of commits on the master branch are:

  1. Tue 9:10 PM
  2. Tue 7:47 PM
  3. Mon 2:46 PM

The history of the pipeline execution show:

  1. Wed 9:14 AM "PR Automated"

So, nothing new has been committed to the Master branch. However, I think I know what's causing this. Just that I'm not convinced on the timing....

So, we have two branches, master and NewBranch.

Master has a policy that requires two code reviewers to Approve, and it requires the build to succeed. Because of this policy, a developer can't therefore merge directly into master - they have to generate a Pull Request.

So, Developer A creates a Pull Request to merge NewBranch to Master. There is then the rather lengthy code review process which may take multiple additional commits to the "NewBranch"'s Pull Request before it's deemed acceptable.

What seems to be happening is that everytime one of these new Commits is sync'd to the Pull Request, a build is triggered. Is this a good thing? Maybe, Maybe not. If the build is going to trigger just once, then the compilation should occur when all the code in the Pull Request has been approved, not before hand. Why trigger a build at such an early stage; the master branch may be updated by multiple other Pull Requests before this is ready to be merged in. However, with unlimited resources, then I guess there's no harm in building as often as possible, but a) this can delay other builds (representing an impediment to other developers) and b) this uses up the free limit on agent time.

Upvotes: 3

Views: 3035

Answers (3)

Mengdi Liang
Mengdi Liang

Reputation: 18978

The detailed info you shared in question is of much help for me to understand the whole workflow of yours.

What you are guessing is correct. The action you faced is expected and by design. The root cause is you are using branch policy and the Build validation also included into this policy.

The nutshell is you are using Pull request trigger.

Explanation:

Let's pay attention to its definition:

Pull request (PR) triggers cause a build to run whenever a pull request is opened with one of the specified target branches, or when changes are pushed to such a pull request.

Based on your added contents, your developers are pushing changes (new commit) into the open Pull request. This belongs to the work scope of the PR trigger because of above definition. That is why the build triggered every time new changes were pushed into NewBranch branch.

Workaround:

I agree with the logic of @devpro's answer. But its script does not available for your scenario. Because the pr in YAML only work for GitHub and Bitbucket Cloud repos.

Here you are using VSTS repo, and configured the policy for it. So, you need to make changes to branch policy configuration. In your Build validation panel, you are setting build policy with Automatic, right?

enter image description here

Please change the Automatic to Manual, also keep the Policy requirement value as Required.

Now, the corresponding build pipeline will not be run automatically once new commit pushed; it can only built when someone runs it manually.

For the delay timing you noticed which make you unsure, I guess it would because of conflict.

For example, the Pull request P1 which merge from NewBranch to Master is opening. I commit a new change C1 into NewBranch. BUT, it causes the conflict. At this time, the build will not be run because the changes are not actually pushed into PR.

Note: The commit is true to NewBranch. BUT changes does not accepted by PR yet, because PR detect out there has conflict here and you must tell PR which changes you want to keep. Only the changes pushed into PR can work with PR trigger.

Only once the conflict is solved and merged into PR will the triggered build run. This would be the time period delay you noticed.

Upvotes: 2

devpro
devpro

Reputation: 365

I think you need to add pr: none to your pipeline definition to disable the automated run.

If pr is not set I think the default is to run on every PR.

That would give something like this:

trigger:
  batch: true
  branches:
    include:
    - master
  paths:
    exclude:
    - README.md

pr: none

Upvotes: 0

Frederik Gheysels
Frederik Gheysels

Reputation: 56934

I've seen the same behaviour today.

Can you try rewriting the trigger part in your pipeline like this:

trigger:
  branches:
    include:
    - master

Does that help ? I can't verify it myself yet, since I've done that change but the PullRequest isn't approved yet :)

I've also another repository where I do not see that behaviour, but there, my pipeline trigger looks like this:

trigger:
  - master

(Notice the 2 spaces before - master)

Upvotes: 0

Related Questions