Azure Question posted in
The official documentation to get you started can be found here.

Azure multi repo trigger – Why is it triggering multiple times for the same commit?

Sample from yml file:

pool:
  name: Managed
  demands:
  - agent.name -equals  Agent2

# Overrides the value for Build.BuildNumber, which is used to name the artifact (ZIP file) that is produced
name: '$(Date:yyyyMMdd)T$(Hours)$(Minutes)$(Seconds)'
resources:
  repositories:
  - repository: RepoA
    type: git
    ref: release/X
    name: company/RepoA
    trigger:
      branches:
        include:
        - release/X

  - repository: RepoB
    type: git
    ref: release/X
    name: company/RepoB
    trigger:
      branches:
        include:
        - release/X

... <more repos and other stuff to build the app> ...

Our application is split into multiple repos. Whenever a commit is made to any repo the pipeline should trigger and build the application (using all repos).

The issue occurs when I work on a feature where I have to make changes to both repos here. That results technically results in two commits (one for RepoA and one for RepoB), which means that this pipeline will trigger twice. This in itself it not so bad since we are self-hosting and don’t pay per run, but the issue is that sometimes the first run will fail, because it does not have the updated code from the other repo. This must be some internal limitation of how Azure works.

This means that in a scenario with a commit to both repos (that is done at the same time), two runs will happen. First run fails, then the second run will start directly after and succeed.

Two questions:

  1. Why is this happening?
  2. How, if possible, can we fix this?
Tags:

2

Answers


  1. 0

    Regarding your first question, please refer to this section of the documentation:

    For the triggering repository, the commit that triggered the pipeline
    determines the version of the code that is checked out. For other
    repositories, the ref defined in the YAML for that repository resource
    determines the default version that is checked out.

    In other words, when your pipeline is triggered by RepoA, it will check out the latest commit from the release/X branch in RepoB. The pipeline might fail if the checkout in the pipeline occurs before the new commit is finalized in RepoB. However, as soon as the second pipeline is triggered by RepoB, the commit in RepoA has already been completed, resulting in a successful pipeline execution.

    Regarding your second question, it’s unlikely that this behavior can be fixed in Azure DevOps, as the system is functioning as intended. The only potential workaround, albeit not an elegant solution, would be to incorporate a delay and clone the non-triggering repository in a subsequent script.

    If this issue poses a significant problem for your workflow, you may need to reconsider and adapt your strategy regarding your repositories.

    Login or Signup to reply.
  2. 0
    1. Why is this happening?

    Specifying a trigger section for multiple repository resources means that any change to these resources will initiate a new run. When you commit changes to both RepoA and RepoB, Azure Pipelines triggers a build for each commit. You can refer the triggers document for multiple repositories for more details.

    You mentioned a scenario with a commit to both repos (that is done at the same time), in the system they are two commits that are processed independently, one after the other. Therefore, the first build does not have the latest changes from the other repository, resulting in failure.

    1. How, if possible, can we fix this?

    From the document:

    This is useful, for instance, in the following scenarios:

    • You consume a tool or a library from a different repository. You want to run tests for your application whenever the tool or library is updated.
    • You keep your YAML file in a separate repository from the application code. You want to trigger the pipeline every time an update is pushed to the application repository.

    This function is intended for the above scenarios.

    Currently, there is no option to disable the first run for your scenario. As a workaround, you may:

    1. Establish a scheduled trigger to execute the pipeline at predetermined intervals.
    2. Turn off automatic triggers and manually initiate the pipeline following updates to both repositories.
    3. Merge the two repos into one repo.

    If the above workaround does not meet your needs, you can request the feature for Azure DevOps here to help the feature better. Engineers usually prioritize features that are urgent or have more votes.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search