-
Notifications
You must be signed in to change notification settings - Fork 65
How CI works
Version: G3v2
Updated: 2022-11-04
This page describes the continuos integration (CI) infrastructure of the second version (G3v2) of this project.
This CI works on the default local building stage on Linux and Windows machines. The Mac OS has not been tested, but it should work equally well.
The CI has been tested also on a local GitLab installation in a Docker container on a Linux machine, but that environment and configuration will be described by some other release later.
Before reading this page it can be helpful to read the pages Concepts of building, Building stages and How building works first.
This CI infrastructure is simple, lightweight and self-content. It does not introduce any additional dependencies. It uses the same building pipeline and the same resources as the non-CI building process.
It essentially consists of a single utility script ci-builder.sh, which uses the utility script builder.sh, which executes the hook scripts of the building pipeline.
By building on the stages similar to the default local stage, that do not natively support CI/CD, is the script ci-builder.sh usually executed manually. Some other means, like using cron jobs, would be certainly possible, if it would make sense in the particular scenario.
On the stages that support CI/CD, like for example the GitLab, is the script ci-builder.sh executed as a part of a CI/CD job. The job can be triggered any way the platform supports.
It should be noticed, that the version G3v2 of the building pipeline offers a significantly higher performance by building sets of images or by repeated builds. It's achieved by utilizing the local g3-cache, which is described separately.
It should be also noticed, that the images are normally re-build and re-published only if they really need a refresh. This can be overridden by setting the environment variable FORCE_BUILDING=1.
It is also a big advantage, that the script ci-builder.sh can build sets of images.
For example, because the each GitLab job runs in a fresh environment, there would be a lot of repeated overhead if the individual images would be built by individual GitLab jobs. Building a set of images by using the script ci-builder.sh allows to do it in a single GitLab job and to share the building environment, Docker builder cache, local g3-cache etc. It results in much shorter building time with fewer resources, eventually making the cloud provider bills lower.
It is not mandatory to use the CI infrastructure. The same images can be built by executing the individual hook scripts of the building pipeline. See the Wiki page How building works for more information.
The utility script ci-builder.sh is intended for building sets of images.
The description of this utility is now stored in the project's repository - see Utility ci-builder.sh.
The utility also offers the embedded help.
The utility script builder.sh is intended for building the individual images and for executing the individual hook scripts of the building pipeline. It is also used by the utility script ci-builder.sh.
The description of this utility is now stored in the project's repository - see Utility builder.sh.
The utility also offers the embedded help.
The project's repository also contains the file Local building example describe the three ways of building the images.