Forum Discussion

azdataguy's avatar
azdataguy
Copper Contributor
Aug 21, 2023

Require latest target branch to be merged as PR check

Hi,

 

we are using feature branches actively. Each branch is merged via a PR.

For a to PR to be merged we run extensive build validations (e.g. build the solution, deploy it, execute it, destroy it).

However, some branches take a bit of time to complete. In this case the have branched of the master several days/weeks ago. This means that in the meanwhile lots of other PRs have overtaken and the master has progressed.

I want every branch to be updated with its target branch and otherwise a build validation to fail.

It seems this has been requested at:

- https://github.com/MicrosoftDocs/azure-devops-docs/issues/8083

- https://stackoverflow.com/questions/64029333/vsts-how-to-require-a-branch-to-be-up-to-date-before-merging-doing-pull-reques

 

However, I am wondering why there is no documented solution today? Do I miss something? Is it overrated because in Azure DevOps PR triggered runs are actually not validating my branch but the result of a merge of my branch with the target branch?

 

Thanks for your support

Felix

2 Replies

  • DavidDalley66's avatar
    DavidDalley66
    Copper Contributor

    Hey! I ran into this with our team’s Azure Repos setup; we wanted to make sure every PR was up-to-date with the target branch before merging, too.What worked for us was enabling the “Require merge to be up to date” policy under Branch Policies in Azure Repos. It blocks the PR from completing unless it’s merged with the latest target branch changes first.
    Here’s the doc that helped me set it up:
    https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops&tabs=browser

  • Azure DevOps PR validations typically run against the result of merging the source branch into the target, not the source branch itself, which means:

    • The build may pass even if the source branch is outdated.
    • Conflicts are only surfaced at merge time, and the PR author isn't forced to resolve them beforehand.

     

    You may try a workaround as Use Build Expiration Policy:

    Simulate this behavior using Build Validation + Build Expiration:

    1. Enable Build Validation on your target branch.
    2. Set Build Expiration to “Immediately when the target branch is updated”

    This forces the PR build to fail if the target branch has changed since the last successful build, nudging the developer to rebase or merge the latest target branch into their feature branch.