- Docker images
- Tagged release builds
Packages built by the
omnibus-gitlab continuous integration pipelines have
a version string in the format
pipelines generally produce three types of packages:
- feature branch builds
- nightly builds
- tagged release builds
build_iterationportion of versions strings conveys a specific meaning and contributes to how
build_versionis computed. The next sections are written with that in mind as
build_iterationmust be understood first even though it comes last in the version string.
Version strings use
build_iteration when packaging related logic changes
that do not contain changes to bundled components.
|Release Type||Example Pipelines||
|non-tagged||feature branches, nightly builds|
The edition component, ce or ee, instructs package managers such as
yum to treat Enteprise Edition packages as an upgrade from
Community Edition when the package version is the same because ee is
sorted lexographically after ce.
OMNIBUS_RELEASE component is deprecated and always set to
OMNIBUS_RELEASE indicated quick bug fixes targeting
omnibus-gitlab with no changes in GitLab Rails or other bundled
components. The updates frequently required Semantic Version updates because
of user impact. For this reason,
OMNIBUS_RELEASE was not useful in
practice and is no longer relevant.
For regular feature branch builds, the version format is
<latest stable git tag>+rfbranch.<pipeline id>.<omnibus-gitlab SHA>-<build iteration>.
As noted above,
build iteration for regular feature branch builds is set to
0. An example version string of this type is
+rfbranch string denotes the package as built from a regular feature
branch build. It also lexographically places it after a stable branch
causing package managers such as
yum to view it as an upgrade
from a stable release package.
For nightly packages , the version format is
<latest stable git tag>+rnightly.<pipeline id>.<omnibus-gitlab SHA>-<build iteration>.
As noted above,
build iteration for nightly builds is set to
0. An example
version string of this type is
+rnightly denotes the package as the output from a nightly build. When
compared alphabetically by package managers,
+rnightly is considered
greater than both the latest stable and the
+rfbranch packages. Package
managers will always treat a nightly package as a package upgrade.
For tagged release builds, while the Git tags are of the format
<SemVer version>+<build iteration>, the version strings follow the format of
<SemVer version>-<build iteration>.
For example, if the tags are
13.1.0+ee.0, the version strings will be
As noted above, unlike feature branch and nightly builds, the
component of these releases are of the format
Docker images created by
omnibus-gitlab CI pipelines are based on the Ubuntu
package built in the previous stage. Hence, the Docker image tag also reflects
the same information given by the package version string. Because
used in package versions is not a supported character for image tags, it is
replaced with a
- to get a slug.
As a general rule, Docker images will use a slug of the package version as tags. Also, all Docker images will be pushed to Docker container registries corresponding to the host where they are being built.
The entire image reference will be of the form
dev.gitlab.org:5005/gitlab/omnibus-gitlab/gitlab-(ce|ee):<slug of package version>
will be the image tag for a Docker built from a GitLab CE package with version
The special cases that deviate from this general rule is listed below.
Triggered builds in QA mirror
Docker images created as part of triggered pipeline (for Package and QA run) has
their tag decided depending on where the trigger originated. If the trigger
originated from an
omnibus-gitlab pipeline, the image tag is the slug of the
package version. But, if the trigger originated from a GitLab or GitLab-FOSS
pipeline, the image tag will be set to the SHA of the commit corresponding to
These jobs are not published to Dockerhub repository.
In addition to the general naming scheme, Docker images built by scheduled
nightly pipelines gets tagged with the
nightly tag and both tags are pushed to
the Dockerhub repository also.
gitlab/gitlab-ce:nightly denote image
references for the two editions available.
In addition to the general naming scheme, Docker images built by tagged release
pipelines also gets tagged as
latest and both tags are pushed to the Dockerhub