Skip to content

Organise CI jobs templates per language

The idea is to provide one directory per language or maybe one file per language.

One directory per language

If one directory per language, we could enable the jobs by default:

  • Git / Lint.yaml
  • Git / Merge-to-dev.yaml
  • Js / Meteor-lint.yaml

Including one file will activate the corresponding job.

The inconvenient for the user is the multiple includes:

# -*- coding: utf-8 -*-
# vim: ft=yaml
---
include:
  - project: EOLE/infra/ci-tools
    ref: stable
    file: /templates/Rules.yaml
  - project: EOLE/infra/ci-tools
    ref: stable
    file: /templates/Runners/apps.education-docker.yaml
  - project: EOLE/infra/ci-tools
    ref: stable
    file: /templates/Git/Lint.yaml
  - project: EOLE/infra/ci-tools
    ref: stable
    file: /templates/Git/Merge-to-dev.yaml
  - project: EOLE/infra/ci-tools
    ref: stable
    file: /templates/Git/Semantic-release.yaml
  - project: EOLE/infra/ci-tools
    ref: stable
    file: /templates/Js/Meteor-lint.yaml
  - project: EOLE/infra/ci-tools
    ref: stable
    file: /templates/Js/Meteor-build.yaml
  - project: EOLE/infra/ci-tools
    ref: stable
    file: /templates/Js/Meteor-test.yaml

stages:
  - lint
  - build
  - test
  - release

And this make difficult to see what will happen just by reading the .gitlab-ci.yml file.

One file per language

If we provide one file per language, it's difficult to enable all jobs by default because some of them may be unwanted.

In this case, the project .gitlab-ci.yaml must declare the jobs

# -*- coding: utf-8 -*-
# vim: ft=yaml
---
include:
  - project: EOLE/infra/ci-tools
    ref: stable
    file: /templates/Rules.yaml
  - project: EOLE/infra/ci-tools
    ref: stable
    file: /templates/Runners/apps.education-docker.yaml
  - project: EOLE/infra/ci-tools
    ref: stable
    file: /templates/Git.yaml
  - project: EOLE/infra/ci-tools
    ref: stable
    file: /templates/Semantic-release.yaml
  - project: EOLE/infra/ci-tools
    ref: stable
    file: /templates/Js.yaml

stages:
  - lint
  - build
  - test
  - release

commit-lint:        { extends: '.git-commit-lint' }
meteor-lint:        { extends: '.js-meteor-lint' }
meteor-build:       { extends: '.js-meteor-build' }
meteor-test:        { extends: '.js-meteor-test' }
semantic-release:   { extends: '.semantic-release:stable' }
merge-to-dev:       { extends: '.git-merge-release-to-dev' }

This has the inconvenient to define jobs in each project .gitlab-ci.yaml.

The advantage is that we can see what will happen just by reading the file.