Matt Critchlow authored Mar 03, 2022 and Vivian Chu committed Mar 08, 2022

In #1020 we articulated a desire and use cases for wanting to, at times,
deploy additional Surfliner applications into a review deployment than
would normally be automatically triggered for a given branch and merge
request.

Initially the thought was to use a dedicated variable, as
`DEPLOY_PRODUCTS`. The downside of this, was that we realized in order
for it to 'stick' on subsequent commits/pushes to the MR branch, it
would require setting that `DEPLOY_PRODUCTS` value using Gitlab's push
otions[0] for every `git push`. And it was agreed that it was just too
likely that this would be easy to forget and not ergonomic enough.

So instead, we're going to overload the existing
`CI_MERGE_REQUEST_LABELS` value, and use the existing labels that we
have for each application to trigger them deploying, when the label is
set for the merge request. We're documenting how to do this for both the
Gitlab UI and `git push` using Gitlab's push options [0] in the
`CONTRIBUTING` file.

This change required moving the CI/CD configuration to using Gitlab's
new rules [1] syntax, which allows for each rule to be evaluated in an
`OR` context, as opposed to the `AND` context we were getting with the
legacy `only` syntax. We are only applying the `rules` changes to
~tidewater, ~comet, and ~superskunk for now. But if this is successful
we need to apply it to the other applications as well.

0. https://docs.gitlab.com/ee/user/project/push_options.html
1. https://docs.gitlab.com/ee/ci/yaml/index.html#rules