- Omnibus-gitlab release process
- How is the official omnibus-gitlab package built
Our main goal is to make it clear which version of GitLab is in an omnibus package.
The official package build is fully automated by GitLab Inc.
We can differentiate between two types of build:
- Packages for release to packages.gitlab.com
- Test packages built from branches available in S3 buckets
Both types are built on the same infrastructure.
Each package is built on the platform it is intended for (CentOS 6 packages are built on CentOS6 servers, Debian 8 packages on Debian 8 servers and so on). The number of build servers varies but there is always at least one build server per platform.
The omnibus-gitlab project fully utilizes GitLab CI. This means that each push to omnibus-gitlab repository will trigger a build in GitLab CI which will then create a package.
Since we deploy GitLab.com using omnibus-gitlab packages, we need a separate remote to build the packages in case of a problem with GitLab.com or due to a security release of a package.
This remote is located on dev.gitlab.org. The only difference between omnibus-gitlab project on dev.gitlab.org and other public remotes is that the project has active GitLab CI and has specific runners assigned to the project which run on the build servers. This is also the case for all GitLab components, eg. gitlab-shell is exactly the same on dev.gitlab.org as it is on GitLab.com.
All build servers run gitlab runner and all runners use a deploy key to connect to the projects on dev.gitlab.org. The build servers also have access to official package repository at packages.gitlab.com and to a special Amazon S3 bucket which stores the test packages.
GitLab Inc is using the release-tools project to automate the release tasks for every release. When the release manager starts the release process, a couple of important things for omnibus-gitlab will be done:
- All remotes of the project will be synced
- The versions of components will be read from GitLab CE/EE repository (eg. VERSION, GITLAB_SHELL_VERSION) and written to omnibus-gitlab repository
- A specific Git tag will be created and synced to omnibus-gitlab repositories
When the omnibus-gitlab repository on dev.gitlab.org gets updated, GitLab CI build gets triggered.
The specific steps can be seen in
.gitlab-ci.yml file in omnibus-gitlab
repository. The builds are executed on all platforms at the same time.
During the build, omnibus-gitlab will pull external libraries from their source locations and GitLab components like GitLab, gitlab-shell, gitlab-workhorse, and so on will be pulled from dev.gitlab.org.
Once the build completes and the .deb or .rpm packages are built, depending on the build type package will be pushed to packages.gitlab.com or to a temporary (files older than 30 days are purged) S3 bucket.
- Pick a tag of GitLab to package (e.g.
- Create a release branch in omnibus-gitlab (e.g.
If the release branch already exists, for instance because you are doing a patch release, make sure to pull the latest changes to your local machine:
git pull https://gitlab.com/gitlab-org/omnibus-gitlab.git 6-6-stable # existing release branch
support/set-revisionsto set the revisions of files in
config/software/. It will take tag names and look up the Git SHA1's, and set the download sources to dev.gitlab.org. Use
set-revisions --eefor an EE release:
# usage: set-revisions [--ee] GITLAB_RAILS_REF GITLAB_SHELL_REF GITLAB_WORKHORSE_REF GITALY_REF # For GitLab CE: support/set-revisions v1.2.3 v1.2.3 1.2.3 1.2.3 # For GitLab EE: support/set-revisions --ee v1.2.3-ee v1.2.3 1.2.3 1.2.3
Commit the new version to the release branch:
git add VERSION GITLAB_SHELL_VERSION GITLAB_WORKHORSE_VERSION GITALY_SERVER_VERSION git commit
Create an annotated tag on omnibus-gitlab corresponding to the GitLab tag. The omnibus tag looks like:
MAJOR.MINOR.PATCHis the GitLab version,
OTHERcan be something like
OMNIBUS_RELEASEis a number (starting at 0):
git tag -a 6.6.0+ce.0 -m 'Pin GitLab to v6.6.0'
WARNING: Do NOT use a hyphen
-anywhere in the omnibus-gitlab tag.
Examples of converting an upstream tag to an omnibus tag sequence:
upstream tag omnibus tag sequence
Push the branch and the tag to both gitlab.com and dev.gitlab.org:
git push firstname.lastname@example.org:gitlab-org/omnibus-gitlab.git 6-6-stable 6.6.0+ce.0 git push email@example.com:gitlab/omnibus-gitlab.git 6-6-stable 6.6.0+ce.0
Pushing an annotated tag to dev.gitlab.org triggers a package release.
The cloud image release process is documented here: https://about.gitlab.com/cloud-images/.
New image are released when:
- There is a new monthly release of GitLab
- A security vulnerability has been fixed in a patch release
- There is a patch that fixes a critical issue impacting the image
New images should be released within 3 business days of the package release.
Image specific release documentation:
- OpenShift: openshift.md.