- I have an MR in
gitlab-org/gitlabproject and want a package or Docker image to test it
- I have an MR in the
omnibus-gitlabproject and want a package or Docker image to test it
- I want to use specific branches or versions of various GitLab components in my build
- I want to use a specific mirror or fork of various GitLab components in my build
- Building packages for other OSs
If you are a member of the GitLab team, you will have access to the build infrastructure (or to the colleagues who have access to the infrastructure) and leverage it to build packages.
In the CI pipeline corresponding to your MR, play the
package-and-qa job in
qa stage. This will trigger a downstream pipeline in
QA mirror which
will get you an Ubuntu 16.04 package and an all-in-one Docker image for testing.
It will also run trigger a
gitlab-qa run using these artifacts too.
GitLab project, pipelines running for MRs in
have manual jobs to get a package or Docker image -
Trigger:ee-package, which as their names suggest builds you CE and EE packages
and Docker images, and will perform a QA run.
Versions of the primary GitLab components like GitLab-Rails, Gitaly, GitLab
Pages, GitLab Shell, GitLab Elasticsearch Indexer are controlled by various
*_VERSION files in
omnibus-gitlab repository and
variables present during the build. Check the table below for details:
|File name||Environment Variable||Description|
|VERSION||GITLAB_VERSION||Controls Git reference of GitLab Rails application. By default, points to |
|GITALY_SERVER_VERSION||GITALY_SERVER_VERSION||Git reference of the Gitaly repository.|
|GITLAB_PAGES_VERSION||GITLAB_PAGES_VERSION||Git reference of the GitLab Pages repository.|
|GITLAB_SHELL_VERSION||GITLAB_SHELL_VERSION||Git reference of the GitLab Shell repository.|
|GITLAB_ELASTICSEARCH_INDEXER_VERSION||GITLAB_ELASTICSEARCH_INDEXER_VERSION||Git reference of the GitLab Elasticsearch Indexer repository. Used only in EE builds.|
|GITLAB_KAS_VERSION||GITLAB_KAS_VERSION||Git reference of the GitLab Kubernetes Agent Server repository.|
If you are running
package-and-qa job from a GitLab MR,
environment variable will be set to the commit SHA corresponding to the pipeline
while other environment variables, if not specified, will be populated from
their corresponding files and passed on to the triggered pipeline.
Temporarily specify a component version using any of the following methods:
*_VERSIONfile, commit and push to start a pipeline, but revert this change before the MR is marked ready for merge. It is recommended to open an unresolved discussion on this diff in the MR so that you remember to revert it.
Set the environment variable via
.gitlab-ci.ymlfile, commit and push to start a pipeline, but revert this change before the MR is marked ready for merge. It is recommended to open an unresolved discussion on this diff in the MR so that you remember to revert it.
Pass the environment variable as a Git push option.
git push <REMOTE> -o ci.variable="<ENV_VAR>=<VALUE>" # Passing multiple variables git push <REMOTE> -o ci.variable="<ENV_VAR_1>=<VALUE_1>" -o ci.variable="<ENV_VAR_2>=<VALUE_2>"
Note: This works only if you have some changes to push. If remote is already updated with your local branch, no new pipeline will be created.
Manually run the pipeline from UI while specifying the environment variables.
Environment variables are passed to the triggered downstream pipeline in the QA mirror so that they are used during builds.
Generally, environment variables are preferred over changing the
files to avoid the extra step of reverting changes. The
*_VERSION files are
most efficient when repeated package builds of
omnibus-gitlab are required,
but the only changes happening are in GitLab components. In this case, once a
pipeline is run after changing the
*_VERSION files, it can be retried to build
new packages pulling in changes from upstream component feature branch instead
of manually running new pipelines.
The repository sources for most software that Omnibus Builds can be found in
.custom_sources.yml file in the
omnibus-gitlab repository. The main
GitLab components can be overridden via environment variables. Check the table
below for details:
|ALTERNATIVE_PRIVATE_TOKEN||An access token used if needing to pull from private repositories.|
|GITLAB_ALTERNATIVE_REPO||Git repository location for the GitLab Rails application.|
|GITLAB_SHELL_ALTERNATIVE_REPO||Git repository location for GitLab Shell.|
|GITLAB_PAGES_ALTERNATIVE_REPO||Git repository location for GitLab Pages.|
|GITALY_SERVER_ALTERNATIVE_REPO||Git repository location for Gitaly.|
|GITLAB_ELASTICSEARCH_INDEXER_ALTERNATIVE_REPO||Git repository location for GitLab Elasticsearch Indexer.|
|GITLAB_KAS_ALTERNATIVE_REPO||Git repository location for GitLab Kubernetes Agent Server.|
If you specifically want a package for an OS other than Ubuntu 16.04, or want to
ensure packages can be built with your change on all OSs, you will have to make
omnibus-gitlab’s Release mirror.
A prerequisite for this is access to push branches to
*_VERSIONfiles or environment variables as specified in the above section if needed. You might want to set
eeenvironment variable in the CI config to
trueto use a commit from GitLab repository instead of GitLab-FOSS.
The pipeline will build packages for all supported OSs, and a Docker image.