Add support for triggering auto-deployments on different GitLab instances, such as dev.gitlab.org or ops.gitlab.net
Auto-deployments are triggered using GitLab.com APIs. If GitLab.com goes down, this means we can't trigger a new auto-deploy.
The code for auto-deploys already supports passing in a different GitLab client, but based on a quick glance over the code it does not change the project paths according to the client that is used. This means that even when passing in a dev or ops client, the code will continue to use GitLab.com project paths.
To resolve this, I propose that we add a feature flag for performing the auto-deploys using a different API host. When this flag is set, we:
- Change the API client that we use
- Change the project paths to match the host that is used
Since most build work happens on dev, I think we should use dev as a fallback; ops.gitlab.net doesn't make much sense as IIRC we don't mirror everything there.
For more information, see the discussion at #1214 (comment 416084871).
- Change the auto-deploy code so that it uses a different project path based on the GitLab API client that is used. This way we'd use the right paths on dev versus GitLab.com
- See #1227 (comment 418261805) for some more info
- Add support for setting an environment flag, and when this flag is set use dev for the auto-deploy process
- Document that flag
- Optionally allow setting this flag using chatops. This is probably not necessary as we can just set it using the CI/CD variables settings page