skip to Main Content

We have a git repo in Azure Devops with a main branch and feature branches. We use a strategy was follows for releases:

  1. Create feature branch from main
  2. Make changes in feature branch
  3. Merge in any changes that have been pushed to main to feature branch
  4. Test and deploy feature branch
  5. Merge feature into main (via PR)

We have a deployment pipeline in Azure Devops with stages for build, test and deployment. The pipeline is triggered when a PR is created to merge the feature branch in the main branch. The instance of the pipeline gets cancelled and a new instance triggered when changes are pushed to the feature branch whilst the PR is open. This has meant that there is always an up to date pipeline for the PR we can release from and this strategy has been working for over a year.

This is our branch policy for the main branch which triggers the pipeline based on a PR with main as the target:
Branch Policy

Recently we have had two instances where the pipeline has not been cancelled and retriggered after changes have been pushed to the feature branch. Specifically this has happened when changes from the main branch were merged in whilst the PR was ongoing. Releasing from the active pipeline would have caused a version of the service with the changes from the feature branch but without the latest changes from main. It was necessary to cancel and manually retrigger the pipeline.

I was wondering if this is new behaviour and if it can be circumvented, it is possible that it has always been this way but after hundreds of releases I think we would have come across it before.

2

Answers


  1. This is the expected behavior.

    When you have a PR between feature and main, the build that is triggered is a merge representation of the two.

    So, when the feature branch got updated with the "new" commits from main, it didn’t trigger the build again because there was nothing new to check, as this has been checked already in the previous run.

    Login or Signup to reply.
  2. I can reproduce your issue. After testing, I found the following:

    • If I commit in feature branch, the pipeline will be triggered. At the same time, I completed the PR merging from main branch to feature branch. But at this time, the pipeline will not be triggered by the commit from main branch.
    • If I merge the main branch into the feature branch after the pipeline is completed: When there are changes in the commit from main, the pipeline can be triggered at this time. When there isn’t any change in the commit from main, the pipeline will not be triggered.
    • If I created new branch newfeature based on feature. Commit in feature branch, the pipeline will be triggered. At the same time, merge from newfeature to feature, the old run will be canceled and a new run will be trigger by the commit from newfeature.

    If there is nothing new for main branch when merging from main branch to feature branch, then for the second case I listed, it seems that the pipeline should not be triggered either.

    As a workaround, it’s suggested that you could merge your main branch to feature after the pipeline is completed.

    I didn’t pay attention to the previous behavior. If merging from main branch to feature branch previously would cancel the old run and trigger a new run, I suggest you report this issue to the Azure DevOps support on Developer Community to confirm if there is any change or it’s bug.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search