This page describes how continuous integration (CI) is used in workers created
For more information on creating workers, see Setting up a worker.
When creating a worker with our official template, a
.gitlab-ci.yml file has
been included with a few actions that will run on every push you make.
The CI jobs will run in the following order:
At Teklia, we use a simple version of Git Flow:
masterbranch should always have validated code and should be deployable in production at any time.
VERSIONfile and using the same version string as the tag name.
This process is reflected the template's
lint job uses pre-commit to run source code linters on your
project and validate various rules:
You can set up pre-commit to run locally too; see Activating the pre-commit hook.
Any unit test you have added to your project will be executed on each git push, allowing you to check the validity of your code before merging it.
Unit tests allow you to prevent regressions in your code when making changes, and find bugs before they make their way into production.
lint jobs run successfully, the
docker job runs. It will
try to build a docker image from your
Dockerfile. This will check that your
Dockerfile is valid and builds an image successfully.
This build step is only used as a check, as Arkindex builds Docker images on its own.
docker job is successful and the CI pipeline is running for a Git
release-notes job runs. It will list all the commits since the
previous tag and aggregate them to publish release notes on the GitLab project.
We provide an open source docker image to build these release notes, but you'll need to provide your own Gitlab access token so that the task can publish release notes on your own repository.
You can generate an access token on the Gitlab's page User Settings > Access Tokens, with
The token must then be set as a CI Variable on your Gitlab project:
Expandin the Variables section
DEVOPS_GITLAB_TOKENwhose value is your token