Prepare a new release

See merge request !28

feat(semantic-release): support prerelease for `testing` and `dev` branches

See merge request !27

New `.on-testing-with-semantic-release-config` and
`.on-dev-with-semantic-release-config` rules.

Create a new `.semantic-release:stable` template job and use it for
the default `semantic-release` job.

* release.config.js: declare 3 variables for `stable`, `testing` and
  `dev` branches.
  By default, `testingBranch` and `devBranch` are undefined and users
  only need to declare them to enable prerelease for them.

The previous `.on-release-tag` match everything starting with
`release/` and so prerelease tags like `release/X.Y.Z-testing` or
`release/X.Y.Z-dev`.

When doing prerelease, we want to avoid updating stable tags, we
restrict the match for release tags and add specific rules to match
`testing` and `dev` tags.

# [1.3.0](https://gitlab.mim-libre.fr/EOLE/infra/ci-tools/compare/release/1.2.1...release/1.3.0) (2022-01-11)

### Bug Fixes

* **semantic-release:** the branch must be `stable` ([4b9152dc](EOLE/infra/ci-tools@4b9152dc))

### Code Refactoring

* **commitlint:** the upstream extra repository is useless ([cdff4abd](EOLE/infra/ci-tools@cdff4abd))

### Documentation

* **commitlint:** describe usage of the commitlint job ([8b3749f0](EOLE/infra/ci-tools@8b3749f0))
* **getting-started:** quick setup and detailed explanations ([007aa219](EOLE/infra/ci-tools@007aa219))
* **readme:** demonstrate a possible release cycle ([8d02a0cf](EOLE/infra/ci-tools@8d02a0cf))

### Features

* **commitlint:** users can configure image with `$COMMITLINT_IMAGE` ([bc7f19c3](EOLE/infra/ci-tools@bc7f19c3))
* **commitlint:** users can configure the base branch ([612dc3ea](EOLE/infra/ci-tools@612dc3ea))
* **docker:** .build-docker-image must accept kaniko arguments ([bd5c77ea](EOLE/infra/ci-tools@bd5c77ea))
* **semantic-release:** don't build changelog on prerelease branches ([5a02f5d2](EOLE/infra/ci-tools@5a02f5d2))
* **semantic-release:** manage python projects releases ([9794bcb0](EOLE/infra/ci-tools@9794bcb0))

### Styles

* **js:** js configuration files do not pass eslint ([5874dca3](EOLE/infra/ci-tools@5874dca3))

fix(semantic-release): the branch must be `stable`

See merge request !26

When doing backport of evolutions from other project, the `branches`
parameter was reset to `master`.

Publish a new release

See merge request !25

Prepare a new release

See merge request !24

feat(semantic-release): manage python projects releases

See merge request !23

* Dockerfile.semantic-release-gitlab: install `semantic-release-pypi`
  and it's dependencies.

* release.config.js: add a commented example of the configuration of
  `semantic-release-pypi`.

feat(docker): .build-docker-image must accept kaniko arguments

See merge request !22

Some users may requires to pass kaniko arguments to set, for example,
some build args required by the Dockerfile.

* templates/Docker.yaml: add `KANIKO_ARGS` optional variable
  overridable by users and pass it to executor command line.

style(js): js configuration files do not pass eslint

See merge request !21

The `commitlint` and `semantic-release` configuration files couldn't
be used as-is in projects running `eslint` on all JS files.

docs(getting-started): quick setup and detailed explanations

See merge request !20

This documentation provides:

- a reminder of some CI concepts
- setup of the project with access token for repository write
  permission
- setup of the `.gitlab-ci.yml` with a full featured example and a
  step by step setup

* README.md: explain the features and add a mermaid graph to show what
  is possible.

feat(semantic-release): don't build changelog on prerelease branches

See merge request !19

By default, `semantic-release` build changelog even for prerelease
branches which looks like duplicated entries to users.

Use a workaround to avoid changelog generation for prerelease branches
by building the configuration in several steps instead of a direct
`module.exports` at the top.

There are no effect on this project since the `branches` configuration
attribute only contains `stable` but can be used for other project
with the only change to declare prerelease `branches`.

* release.config.js: rework the configuration file to conditionnally
  execute `@semantic-release/changelog` and add its assets to the git
  plugin.

feat(commitlint): users can customise the docker image and the base branch to use

See merge request !18

Verify formatting of all commit messages in the range
`$BASE_BRANCH..$CI_COMMIT_SHA`.

USAGE
=====

include:
  - project: EOLE/infra/ci-tools
    ref: stable
    file: /templates/Rules.yaml
  - project: EOLE/infra/ci-tools
    ref: stable
    file: /templates/Lint/Commitlint.yaml

stages:
  - lint

OPTIONAL VARIABLES
==================

- `BASE_BRANCH`: name of the referrence branch, defaults to
  `${CI_DEFAULT_BRANCH}`
- `COMMITLINT_IMAGE`: name of the `commitlint` docker image to use

REQUIREMENTS
============

- The `.not-on-stable` rules template
- A `lint` stage must be present in your pipeline or it must be
  overriden by the extending job to feet your need.

USED CI VARIABLES
=================

- `CI_COMMIT_SHA`
- `CI_DEFAULT_BRANCH`

Users can override the variable `BASE_BRANCH` in their
`.gitlab-ci.yml` to select the starting point of the logs to
validate.

Users can override the variable in their `.gitlab-ci.yml` to select
another docker image.

There is no need to add an upstream repository to access
`${CI_DEFAULT_BRANCH}` we just neet to fetch all references from
`origin`.

Avoid the use of `before_script` and `after_script` for users of the
job to be able to extend it with them.

## [1.2.1](https://gitlab.mim-libre.fr/EOLE/infra/ci-tools/compare/release/1.2.0...release/1.2.1) (2021-12-09)

### Code Refactoring

* **rules:** permit to combine individual rules ([075712a9](EOLE/infra/ci-tools@075712a9)), closes [#3](EOLE/infra/ci-tools#3)

refactor(rules): permit to combine individual rules

Closes #3

See merge request !17

The previous rules template set did not permit to combine rules easily
in user jobs.

Using a single hash of individual rules permit to reference them more
clearly. It avoids duplicated conditionnals in the current rules set
and marke it easier to combine them in user jobs, with some
limitations[1].

* templates/Rules.yaml: define the `.rules-map` hash of individual
  rules and reference them in rules templates

* templates/Release/Semantic-release.yaml: use the `.rules-map`
  directly to reduce the conditionnal duplication

Closes #3

Footnotes:
[1]  https://forum.gitlab.com/t/add-conditions-to-rules-array-merged-with-reference/62600

# [1.2.0](https://gitlab.mim-libre.fr/EOLE/infra/ci-tools/compare/release/1.1.0...release/1.2.0) (2021-12-06)

### Features

* **rules:** we want to skip pipelines on more keywords ([0a24edbe](EOLE/infra/ci-tools@0a24edbe)), closes [#2](EOLE/infra/ci-tools#2)
* **runners:** apps.education projects will use dedicated runners ([3f447c40](EOLE/infra/ci-tools@3f447c40)), closes [#1](EOLE/infra/ci-tools#1)

Release the ci-tools for apps.education

See merge request EOLE/infra/ci-tools!15

Prepare a release to support apps.education projects

See merge request EOLE/infra/ci-tools!14

feat(rules): we want to skip pipelines on more keywords

Closes #2

See merge request !13

feat(runners): apps.education projects will use dedicated runners

Closes #1

See merge request EOLE/infra/ci-tools!12

Gitlab does not permit to easily add pattern to skip CI pipelines
based on commit messages[1].

* templates/Rules.yaml: exclude commits with message matching some
  variations around `draft` and `wip`.

Closes: #2

Footnotes:
[1]  https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/pipeline/chain/skip.rb

Closes #1

# [1.1.0](https://gitlab.mim-libre.fr/EOLE/infra/ci-tools/compare/release/1.0.0...release/1.1.0) (2021-11-30)

### Features

* **semantic-release:** use the image build by CI itself ([ba0d0241](EOLE/infra/ci-tools@ba0d0241))