- Test a
gitlab-org/gitlabproject merge request
- Test an
- Use specific branches or versions of a GitLab component
- Use a specific mirror or fork of a GitLab component
- Build packages for other operating systems
If you are a GitLab team member, you have access to the build infrastructure or to the colleagues who have access to the infrastructure. You can use that access to build packages.
If you have a merge request (MR) in the
gitlab-org/gitlab project, you can
test that MR using a package or a Docker image.
In the CI pipeline corresponding to your MR, run the
e2e:package-and-test job in
qa stage to trigger:
- A downstream pipeline in the
omnibus-gitlabQA mirror, which gives you an Ubuntu 20.04 package and an all-in-one Docker image for testing.
gitlab-qarun using these artifacts as well.
If you have an MR in the
omnibus-gitlab project, you can
test that MR using a package or a Docker image.
Similar to the
GitLab project, pipelines running for MRs in
have manual jobs to get a package or Docker image. The
Trigger:ee-package jobs build CE and EE packages and Docker images and perform a QA run.
Versions of the primary GitLab components like GitLab Rails or Gitaly are controlled by:
*_VERSIONfiles in the
*_VERSIONenvironment variables present during the build.
Check the following table for more information:
|VERSION||GITLAB_VERSION||Controls the Git reference of the GitLab Rails application. By default, points to the |
|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 the
e2e:package-and-test job from a GitLab MR, the
environment variable is set to the commit SHA corresponding to the pipeline.
Other environment variables, if not specified, are 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. We recommend you open an unresolved discussion on this diff in the MR so you remember to revert it.
Set the environment variable in the
.gitlab-ci.ymlfile, commit and push to start a pipeline, but revert this change before the MR is marked ready for merge. We recommend you open an unresolved discussion on this diff in the MR so 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 is 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.
You should use environment variables instead of changing the
files to avoid the extra step of reverting changes. The
*_VERSION files are
most efficient when you need repeated package builds of
but the only changes happening are in GitLab components. In this case, when a
pipeline is run after changing the
*_VERSION files, it can be retried to build
new packages pulling in changes from the upstream component feature branch instead
of manually running new pipelines.
The repository sources for most software that Omnibus builds are in
.custom_sources.yml file in the
omnibus-gitlab repository. You can override
the main GitLab components using 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.|
- You must have permission to push branches to the
Use the release mirror to:
- Build a package for an operating system other than Ubuntu 20.04.
- Ensure packages with your changes can be built on all operating systems.
To build packages for other operating systems:
*_VERSIONfiles or environment variables as specified in the previous section if needed. You might want to set the
eeenvironment variable in the CI configuration to
trueto use a commit from the GitLab repository instead of GitLab-FOSS.
Push your branch to the release mirror and check the pipelines.
The pipeline builds packages for all supported operating systems and a Docker image.