This issue has arisen as a result of the following original request: https://bitbucket.org/site/master/issues/13676/ability-to-restrict-who-can-run-deployment
As per the original suggestion in the above request, ops configuration should only ever be read from a single branch. This would work well with branch restrictions already available within Bitbucket Pipelines.
Since the original suggestion did not get implemented, the same issues relating to security still exist. One such example can be seen by the following use-case.
=== Use-case ===
pull-requests: '**': - step: script: - sh run-tests-and-auto-merge-if-coverage-sufficient.sh # Since the above needs to be performed on every branch, it follows that any API keys used is accessible on every branch. services: - docker
There's nothing to stop a user from modifying the sufficiency test within
run-tests-and-auto-merge-if-coverage-sufficient.sh and push the changes to the branch that they are working on. As it currently stands, Bitbucket Pipelines will recognise and make use of the updated
=== End of Use-case ===
Unlike the original suggestion, it's not sufficient to only read contents of the
bitbucket-pipelines.yml file from a single branch. In most setups, this yml file will reference other files (in the use-case above,
run-tests-and-auto-merge-if-coverage-sufficient.sh is one such file).
Therefore, it's important to first define what an ops configuration is. To me, it's any file that is utilised within your pipelines, including of course (but not limited to)
While having a separate repo for your ops configuration is one solution, a more simpler one would be to simply have BitBucket Pipelines recognise a directory at the root of your code repo. Let's call this directory
bitbucket-pipelines.yml could stay at its current (expected) location to maintain backwards compatibility. All your other scripts can then go under
.pipelines and the single branch that is responsible for providing the true copy can then be set.