Create omnibus pipeline for automatic staging deployments
For an overview of how this task fits into the design for automatic staging deployments see the feature description in the associated epic
Currently when we tag a release a pipeline is constructed that includes a step to deploy to staging.gitlab.com as soon as the ubuntu package is built.
What we probably want is a new pipeline that can be triggered which generates a branch build (https://gitlab.com/gitlab-org/omnibus-gitlab/tree/master/doc/build#building-a-package-from-a-custom-branch) that also makes the package available for installation so we can trigger a deploy pipeline to install it.
We only need to create an ee package for this pipeline.
The pipeline would only be triggered for the omnibus auto-deploy branch that was created in https://gitlab.com/gitlab-org/release/framework/issues/259
We should try to make this pipeline as fast as possible, only build what we need and maybe even bypass packagecloud.
Does this pipeline need to upload the package to packagecloud?
For now yes, we will use packagecloud but the option remains open to instead use a bucket if it saves us time.
How will it be triggered?
- When there is an omnibus change that is merged into the branch we want to trigger a build to staging
- When there is an update to an
auto-deploy
gitlab-ee branch we will want this pipeline to be triggered
What pipeline variables will be necessary?
- DEPLOY_VERSION: I think the
omnibus-gitlab/VERSION
file will have the branch name which we can combine with the commit SHA to come up with a unique version for the package. Example:auto-deploy-11.10-1234-$CI_COMMIT_SHA
Where1234
would be the original pipeline ID of the release-tools job that created the branch. - DEPLOY_ENVIRONMENT: I think we should just default this to gstg
How can we be sure that we don't have two pipelines running in parallel, what do we do if there is a pipeline already in progress?
TBD
auto-deploy-*
branches which would auto-deploy to staging?
How do we prevent anyone from pushing changes to these Maybe not a huge concern, but we might be able to make them protected