GitLab CI for workers¶
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:
defaultbranch should always have validated code and should be deployable in production at any time.
- Developments should happen in branches, with merge requests to enable code review and Gitlab CI pipelines.
- Project maintainers should use Git tags to create official releases, by
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:
- Checking your Python code is PEP8 compliant
- Auto-formatting your Python code using black
- Sort your Python imports
- Check you don’t have any trailing white space
- Check your YAML files are well formatted
- Fix some common spelling errors
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.
Generating release notes¶
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:
- go to your project settings,
- go to section CI / CD
- click on
Expandin the Variables section
- add a new variable named
DEVOPS_GITLAB_TOKENwhose value is your token