Skip to content

GitLab CI for workers

This page describes how continuous integration (CI) is used in workers created using the base-worker template.

Default template

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:

flowchart TB
    test & lint --> docker
    docker -- on tag --> release-notes

Git Flow

At Teklia, we use a simple version of Git Flow:

  • The default branch 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 updating the project.version key of the pyproject.toml file and using the same version string as the tag name.

This process is reflected the template’s .gitlab-ci.yml file.

Linting

The 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.

Testing

The test job uses tox and pytest modules to run written unit tests for your repository and avoid any kind of code regression.

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.

Building

When the test & 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

When the docker job is successful and the CI pipeline is running for a Git tag, the 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 api scope.

The token must then be set as a CI Variable on your Gitlab project:

  1. go to your project settings,
  2. go to section CI / CD
  3. click on Expand in the Variables section
  4. add a new variable named DEVOPS_GITLAB_TOKEN whose value is your token