The branch name / glob pattern in the pull-request pipeline definition is the source branch that should trigger that pipeline, not the target branch.
E.g. if you were following git-flow instead of github-flow, it would make sense to override the pipeline run by the PR from main
to a release/whatever
branch so that it simply passes, or does an integration test, but does not perform the usual tests, linting, coverage and whatnot.
pipelines:
pull-requests:
'**': # triggers if no other specific pipeline was triggered
- parallel:
- step: *linting-step
- step: *testing-step
main: # triggers from main to anywhere else
- step:
name: Pass
script:
- exit 0
If following github-flow, you will probably never make a PR from main
to anywhere else, so you can safely skip this definition. Only if you wanted PRs from feature/AAA-NNNN
branches to trigger a special pipeline besides the testing workflow, you can write an alternate pipeline like
pipelines:
pull-requests:
'**': # triggers if no other specific pipeline was triggered
- parallel:
- step: *linting-step
- step: *testing-step
feature/*: # triggers from feature/* to anywhere else (including to main)
- parallel:
- step: *linting-step
- step: *testing-step
- step: *maybe-hook-issue-tracker-step # ?
so that the simpler default '**'
pipeline will not run. But it will run irrespective of the target branch, usually main
but not necessarily.