You can only have one pipeline, but you can filter workflows within the pipeline based on branch or tag. So use branch / tag filters and dependencies.
For example, have your basic test / lint / etc. workflows run on everything. Then have a deploy workflow that depends on those workflows (or not), but has a branch filter only on main or whatever your trunk branch is. Something like this simple example (note: this is just the workflows section).
(you can also add manual approval jobs if you want them).
Another way is to cut a tag on the merge to trunk, then do more things off of that cut tag. This is useful if you’re using a system like semantic-release to gate releases (i.e., run the thing that cuts the tag under certain conditions on the trunk branch only, then have your deploy workflow hang off the tag). If you’re filtering on both branches and tags, you’ll want to either use two different workflows or make sure you allow /.*/ for the tags if some jobs within the same workflow filter on a tag.
You can use YAML anchors to slightly dry up the config around filters if you’ve got a lot of things that use the same filter.
Would it also be possible to include path filtering with this using circleci/path-filtering ?
So to try and have different jobs based on folder path on the main branch ?
To add to my previous question
When a PR is raised - run a verification job with steps consisting of build checks
Once build check job (above) is successful and the PR is approved and merged - run further steps on merged branch conditionally based on path filtering and on success deploy to prod
You mean on the branch that was merged into (i.e., trunk), right, vs. further steps on the branch that was already merged?
I have only used the path filtering orb a little, but yes, I don’t see why not. You’d just set the right parameters in the setup workflow, and then use them where needed.