DevOps Pipeline Trigger on different branches but same commit-CodePudding

There is a build pipeline that triggers each time if a branch is uploaded to the git-Repo on DevOps.

The yml file for the pipeline is in every branch (It is limited to a directory in the Repo by the yml-file, but not to any branch or something else)

trigger:
 paths:
   include:
     - directory/anotherdirectory
resources:
- repo: self

I push the local develop-Branch to the DevOps-Repo and the build pipeline starts as expected. Then I create locally a new release-Branch based on the develop-Branch, but without any change, so that both branches point to the same commit. When I push the new local release-Branch to the DevOps-Repo, the build pipeline does not start. (No pipeline entry is created)

Is there something that recognizes, that the commit has already been build (in the pipeline), unless from which branch? Can I force to build the same commit when pushing different branches. Or do I miss something.

I also tried to have a feature/1-Branch that builds and created a feature/2-Branch for the same commit and it also did not start the pipeline build, to exclude that it's a filter problem on the branchnames.

CodePudding user response：

trigger:
 paths:
   include:
     - directory/anotherdirectory

This trigger means that pipeline will be triggered if there are any changes in directory/anotherdirectory. When you push branch without any changes - pipeline will be not triggered. If you want to trigger pipeline always, you need to modify your triggers, or remove them.

CodePudding user response：

I guess, I found a solution, that requires to add the branch to the trigger.

trigger:
 branches:
    include:
      - '*'
 paths:
   include:
     - directory/anotherdirectory

The asterisk is for all branches.

It is also described in the documentation to add the branches when using paths https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/azure-repos-git?view=azure-devops&tabs=yaml#paths. I don't know why it worked without branches.

Not sure, but that maybe generates an internal "key" of branch and directory, so that the trigger recognizes that there wasn't already a build on branch and current directory files. So if there have been a build on the same current directory files the trigger executes for the different branch.