Cross repo triggers how-to

[rosieyohannan]

Written with Claude code for help with structure, use case and examples

Adds a how-to guide for setting up cross-repo triggers with two pathways, one in which the config is stored with the code and one in which a centralised config repo is used.

Diagrams included render like this:

[BeFunes]

Just a couple more things to double check and (maybe) tweak, I can help with that! I also would want to give it a test run.

[BeFunes]

Approved.
Just left two comments about the tag filters, lmk if you wanna chat about them

[BeFunes]

I've tested, and this is actually not needed because the TAG is triggering the pipeline, but the checkout reference is a branch, not a tag.
It's super confusing, but basically no tag filter is needed

[BeFunes]

So all of this can be removed too. I'm almost tempted to say we should leave it to avoid confusing customers, but truly - it's not needed 😢

[rosieyohannan]

How about if I remove but then add a note that if you don't use the tag trigger but instead choose all pushes you need it? and just point people to where we explain in the workflows doc: https://circleci.com/docs/guides/orchestrate/workflows/#executing-workflows-for-a-git-tag but actually that section needs updating too to reference the ability to use a tag trigger?

[BeFunes]

Using the "Tag pushes" triggers is not the reason why this is not needed, it's more nuanced than that.
It's still true that when you use "Tag pushes", in a single repo situation you will need that filter.

The reason is that the filter: \n tags: filter behind the scenes looks at the pipeline value pipeline.git.tag, which is only populated if the checkout ref is a tag.
In this situation, pipeline.git.tag is empty, because we're checking out a branch (main). The fact that you're triggering through tag does not affect it.

I don't think this is how things should work, but at the moment it's the reality, unfortunately.