Pipeline completion trigger is defined in the pipeline definition of triggered pipeline.

Schema

pipelines:
- pipeline: string # Required as first property. ID of the pipeline resource.  ([-_A-Za-z0-9]*)
  project: string # Project for the source; defaults to current project.. 
  source: string # Name of the pipeline that produces the artifact.. 
  version: string # The pipeline run number to pick the artifact, defaults to latest pipeline successful across all stages; used only for manual or scheduled triggers.. 
  branch: string # Branch to pick the artifact. Optional; defaults to all branches, used only for manual or scheduled triggers.. 
  tags: [ string ] # List of tags required on the pipeline to pickup default artifacts. Optional; used only for manual or scheduled triggers. 
  trigger:  # Specify none to disable, true to include all branches, or use the full syntax as described in the following examples.
    enabled: boolean # Whether the trigger is enabled; defaults to true..  (false,n,no,off,on,true,y,yes)
    branches:  # Branch conditions to filter the events, optional; Defaults to all branches.
      include: [ branchFilter ] # List of branches to include. 
      exclude: [ branchFilter ] # List of branches to exclude. 
    stages: [ string ] # List of stages that when complete will trigger the pipeline. 
    tags: [ string ] # List of tags that when matched will trigger the pipeline.

A pipeline resource has two places related to “branch”

• branch attribute
• branches filter: branches under trigger

Branch attribute

Branch attribute is ONLY significant for manual or scheduled trigger. To ensure the triggering pipeline from the same branch is automatically selected when starting a triggered pipeline manually: in the yaml definition of the triggered pipeline, make sure the branch attribute of the triggering pipeline resource is set as $. This way the source branch for the triggered pipeline is used to specify the branch for the triggering pipeline.

Branches filter

Branches filter allows the triggering to ONLY happen based on certain branches (of the triggering pipeline).

Evaluation of triggering

For a given yaml template that represents the definiton of a pipeline, it could exist across multiple branches and they may differ from each other. It is the pipeline version in the branch specified by Default branch for manual and scheduled builds being use for triggering evaluation.

• If two pipelines are in different repositories, it will always be the branch defined under Default branch for manual and scheduled builds in the triggered repository being run. i.e.: There is no way to dynamically match branch between triggering and triggered pipelines.
• If two pipelines are in the same repository, the triggered pipeline version in the same branch as the triggering pipeline is run. i.e.: branches between triggering and triggered pipeline will automatically match up.

Known issues

Based on current settings, i.e.: both triggering(build) and triggered(deployment) has triggered configured with path filter

• When changes are committed in both src and pipeline/resource folder - deployment pipeline will be triggered twice, one automtatically triggered from the build, one individual CI triggered from the deployment pipeline itself.
• The build will not be automatically triggerd when a new branch is created: Behavior of triggers when new branches are created

Reference

• Branch considerations
• Default branch for manual and scheduled builds
• Behavior of triggers when new branches are created