While I am posting this, i disagree with its conclusion.
A seperate repo for your config is neither the only solution, nor is a particularly comprehensive one.<p>For one, your deployment scripts,
and other things that can escape the container, are almost certainly using Secrets. E.g. secured enviroment variables.
Your CI server should be configured to only share those Secrets with PRs coming from trusted branches.<p>*Otherwise they can simply `println(DEPLOY_KEY)` even if the CI config is on another branch*; unless you also don't show the logs etc.<p>TravisCI for example only trusts PRs from your own repo. It doesn’t give secrets to PRs from forks.
<a href="https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions" rel="nofollow">https://docs.travis-ci.com/user/pull-requests/#pull-requests...</a><p>---<p>I feel like it is a thing to not use the CI configuration of the branch, but to always use the CI configuration of master/main.
At least for untrusted branches.
This ensures that someone has code-reviewed the CI config before it runs.
(Still doesn’t help with malicious tests though, but nor does a seperate repo. But see above re: secrets that allow escaping container)<p>I thought this was the default for TravisCI but it seems not.
You can turn it on though, it is the same mechanism as for a seperate repo.
<a href="https://docs.travis-ci.com/user/build-config-imports#importing-configs-from-the-same-repository" rel="nofollow">https://docs.travis-ci.com/user/build-config-imports#importi...</a>