do not run kitchen tests twice (on .com and on ops)
The way our chef repos are configured is that the same tests need to run twice on the .com instance and on the ops instance before a change can be applied to our infrastructure. This means that a config change can take ~30min before it can be rolled out. Here's an example, com pipeline: https://gitlab.com/gitlab-cookbooks/gitlab-exporters/-/pipelines/177591306 and ops pipeline: https://ops.gitlab.net/gitlab-cookbooks/gitlab-exporters/-/pipelines/232934
In order for a change to be rolled out, the cookbook needs to be published (push-cookbook job on the ops needs to run: https://ops.gitlab.net/gitlab-cookbooks/gitlab-exporters/-/jobs/1653048 ). This job runs on master branch on ops which is mirrored from the master branch on .com . In order for the push-cookbook job to run, all previous jobs in the CI pipeline need to succeed. So from the moment the master branch from .com is mirrored onto ops it takes ~15mins to publish the config change and all kitchen tests + push-cookbook jobs need to run. On the .com side, in order for a change to end up on master, it needs to go through an MR and you can't merge an MR without a successful pipeline which runs the kitchen tests. So all in all, the exact same kitchen tests run twice on the exact same git ref. Another way to explain it, the workflow is as follows: branch off of master -> push a change -> create an MR -> pipeline runs on .com (takes ~15mins, includes kitchen tests) -> MR is merged to master on .com -> master is synced between .com and ops -> pipeline runs on ops (takes ~15mins, includes kitchen tests)