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.

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.

This make a better distinction between `stable` software and software
deployed in production.

We define 3 branches:
- `dev`: new developped features are integrated here, this is the
  default branch
- `testing`: is a fork of `dev` when we want to prepare the next
  release, this is the branch from where release bugfixes are derived
  and merged back
- `stable`: is where the `testing` branch is merged to produce a new
  release

We define rules to match somewhate a git-flow style workflow to
activate jobs:

- `.not-on-prod`: on all branches except production

- `.on-branches` : on supporting branches, i.e. everything except
  production and developpment

- `.on-dev`: on developpment branch only

- `.on-prod`: on production branch only

- `.on-release-tag`: on the release tag only

We always exclude pipeline triggered from schedule.

* templates/Rules.yaml: define the new rules templates.

* templates/Lint/Commitlint.yaml (commitlint): execute on all branch
  except production.

* templates/Lint/Commitlint.yaml (commitlint): use
  `$CI_DEFAULT_BRANCH` as base to calculate the list of commits to check.

This will permit other projects to
[include](https://docs.gitlab.com/ee/ci/yaml/#include) the defined
templates

The `templates/Rules.yaml` must be included and jobs will `extends`
the templates depending at which moment they must be executed.