This guide is aimed at developers and packagers, to explain how the Chakra GitLab CI instance works and how to use it.
GitLab comes with a Continuous Integration feature (CI, for short) that can build and test software at each new commit. The tool is flexible enough to be used for other purposes - in Chakra we use the GitLab CI workflow to build packages on request.
The key concepts are:
This defines a list of stages to be executed in the order specified in the
This defines what should be done and when, as specified in the
.gitlab-ci.ymlfile. When executed, it is called a job.
This is the execution process of stages.
The current workflow has been defined like this:
How to build packages
- Push a new commit with a keyword in the commit message. This is the most interesting part - keywords are used to change the CI behaviour (also see Commit content below):
Skip the CI workflow and don’t trigger the package building process.
Specify a repository to build against that will also be the upload destination, e.g.
[staging] rest of commit message here
- [desktop] and [gtk] packages are built against [core], [desktop], [lib32], and [gtk]
- [core] and [lib32] packages are built against the above and [testing]
- All packages are uploaded to [testing]
- The package building process is automatically started.
- When done, the
deploy_pkgsjob can be started manually, and the package(s) are moved to the corresponding repository.
These are the files that the CI scripts can handle:
The specified package is built based on the committed and pushed
PKGBUILDfiles can be included in a single commit - the build script automatically sorts them based on their dependencies and start the build process.
.orderfile is modified, the CI script will read the entire file, sort the content by dependencies, and start the build process.
It is currently not possible to build the current definition of package groups, because the script can not parse the external configuration file.
Currently CI-enabled repositories
Last updated on 2018-03-03.