We want to tag images based on the different steps of the release
cycle:

- `dev` images where developpement is integrated
- `testing` images where releases are stabilised
- `stable` images when the release is done
  - `major` tag with only the first digit of the semantic version,
    this tag will always point to the latest release of the major
    version
  - `minor` tag with only the first 2 digits of the semantic version,
    this tag will always point to the latest release of the minor
    version
  - `release` tag with the full semantic version
  - `latest`/`stable` point to the latest stable image

Define `.tag-docker-image` template used by `*-docker-tag` jobs It tag
the `${IMAGE_NAME}:${SOURCE_TAG}` with the tag `${IMAGE_TAG}`

USAGE
=====

foo-docker-tag-devel:
  extends: .tag-docker-image
  variables:
    IMAGE_TAG: 'devel'

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

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

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

- `IMAGE_NAME`: defaults to `${CI_JOB_NAME}` with any suffix
  `-docker-tag*` removed
- `SOURCE_TAG`: source image tag to retag, defaults to
  `git-${CI_COMMIT_SHORT_SHA}`
- `IMAGE_TAG`: image tag, defaults to `${CI_COMMIT_TAG}` with prefix
  `RELEASE_PREFIX` removed
- `RELEASE_PREFIX`: prefix of the `RELEASE`, defaults to `release/`

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

- `CI_REGISTRY`
- `CI_REGISTRY_USER`
- `CI_REGISTRY_PASSWORD`
- `CI_REGISTRY_IMAGE`

Define `.build-docker-image` template used by `*-docker-build` jobs It
build the container image and push it to `${CI_REGISTRY}`

USAGE
=====

foo-docker-build:
  extends: .build-docker-image
  variables:
    DOCKERFILE: Some-specific.Dockerfile
    IMAGE_TAG: $CI_COMMIT_REF_SLUG

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

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

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

- `IMAGE_NAME`: defaults to `${CI_JOB_NAME}` with any suffix
  `-docker-build*` removed
- `DOCKERFILE`: defaults, in order
   - to value set by the user
   - to `Dockerfile.${IMAGE_NAME}` if the file exists
   - to `Dockerfile` if the file exists
- `IMAGE_TAG`: defaults to `git-${CI_COMMIT_SHORT_SHA}`

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

- `CI_REGISTRY`
- `CI_REGISTRY_USER`
- `CI_REGISTRY_PASSWORD`
- `CI_REGISTRY_IMAGE`

Create new release when merge requests are merged into the
`$STABLE_BRANCH` branch.

* templates/Release/Semantic-release.yaml: run `semantic-release` with
  the latest EOLE container for `$STABLE_BRANCH` branch if one of its
  configuration is present.

* .gitlab-ci.yml: execute a new stage `release` for
  `semantic-release`.

* release.config.js: create `docs/CHANGELOG.md` and publish new
  releases on Gitlab.
  Mangle commits to have links for users, issues and commits id.

* release-rules.js: create semantic version update rules based on
  `docs/CONTRIBUTING.md`.

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.

* .gitlab-ci.yml: define only stage `lint` for now and run
`commitlint` at that stage.

* docs/CONTRIBUTING.md: describe the commit message formatting rules.

* README.md: link to the contributing guide.