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 .gitlab-ci.yml file.
This defines what should be done and when, as specified in the .gitlab-ci.yml file. When executed, it is called a job.
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.
[testing] or [staging]
Specify a repository to build against that will also be the upload destination, e.g.
[staging] rest of commit message here
If no keyword is specified in the commit message, the defaults are used:
[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_pkgs job 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 PKGBUILD. Multiple PKGBUILD files can be included in a single commit - the build script automatically sorts them based on their dependencies and start the build process.
If an .order file 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.