Building a docker image is now done by `.docker:image:build` job
template.

Tagging a docker image is now done by `.docker:image:tag` job
template.

We keep the previous job templates for backward compatibility.

* templates/Docker.yaml: new `.docker:image:build` and
  `.docker:image:tag` job templates.

Using `semantic-release` require the users to include
`templates/Semantic-release.yaml` and `extends` the `.semantic-release:*`
job templates.

We keep `templates/Release/Semantic-release.yaml` for backward
compatibility.

* templates/Semantic-release.yaml: new `semantic-release` related job
  templates

* templates/Lint/Commitlint.yaml: define `semantic-release` with the
  `.semantic-release:stable` job template for backward compatibility.

Using `commitlint` require the users to include `templates/Git.yaml`
and `extends` the `.git:commitlint` job template.

We keep `templates/Lint/Commitlint.yaml` for backward compatibility.

* templates/Git.yaml: new git related job templates

* templates/Lint/Commitlint.yaml: define `commitlint` with the
  `.git:commitlint` job template for backward compatibility.

* .commitlintrc.yaml: move from JS to YAML.

Instead of having files with executable jobs, we define only hidden
template jobs that users must `instanciate` in their own
`.gitlab-ci.yml`.

feat(docker): tag docker image of contributor branches

See merge request !33

feat(semantic-release): update to version `19`

See merge request !32

feat(commitlint): update `commitlint` to version 16

See merge request !31

feat(semantic-release): new job templates for prerelease

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

The docker image build for `$TESTING_BRANCH` is done after
`semantic-release` version generation.

By default, a `semantic-release` job is created for `$STABLE_BRANCH`
and you can create jobs for `$TESTING_BRANCH` and `$DEV_BRANCH` by
extending the `.semantic-release:testing` and `.semantic-release:dev`
template jobs.

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

See merge request EOLE/infra/ci-tools!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 EOLE/infra/ci-tools!26

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

Publish a new release

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

Prepare a new release

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

feat(semantic-release): manage python projects releases

See merge request EOLE/infra/ci-tools!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 EOLE/infra/ci-tools!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 EOLE/infra/ci-tools!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 EOLE/infra/ci-tools!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 EOLE/infra/ci-tools!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 EOLE/infra/ci-tools!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)