We have a git repo in Azure Devops with a main
branch and feature
branches. We use a strategy was follows for releases:
- Create
feature
branch frommain
- Make changes in
feature
branch - Merge in any changes that have been pushed to
main
tofeature
branch - Test and deploy
feature
branch - 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:
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
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.
I can reproduce your issue. After testing, I found the following:
feature
branch, the pipeline will be triggered. At the same time, I completed the PR merging frommain
branch tofeature
branch. But at this time, the pipeline will not be triggered by the commit frommain
branch.main
branch into thefeature
branch after the pipeline is completed: When there are changes in the commit frommain
, the pipeline can be triggered at this time. When there isn’t any change in the commit frommain
, the pipeline will not be triggered.newfeature
based onfeature
. Commit infeature
branch, the pipeline will be triggered. At the same time, merge fromnewfeature
tofeature
, the old run will be canceled and a new run will be trigger by the commit fromnewfeature
.If there is nothing new for
main
branch when merging frommain
branch tofeature
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 tofeature
after the pipeline is completed.I didn’t pay attention to the previous behavior. If merging from
main
branch tofeature
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.