# 1.0.0 (2021-11-30)

### Continuous Integration

* **codeowners:** define @EOLE group members as owners ([5f57f4a0](EOLE/infra/ci-tools@5f57f4a0))
* **commitlint:** master is not always the repository default branch ([48b9f29c](EOLE/infra/ci-tools@48b9f29c))
* **gitlab-ci:** split in reusable templates ([b39e36bd](EOLE/infra/ci-tools@b39e36bd))
* **gitlab:** add commit lint and its documentation ([dfea8470](EOLE/infra/ci-tools@dfea8470))
* **rules:** define git-flow style rules ([e8e12e8f](EOLE/infra/ci-tools@e8e12e8f))

### Features

* **docker:** build images and push them to `${CI_REGISTRY}` ([a18d1f90](EOLE/infra/ci-tools@a18d1f90))
* **docker:** tag images based on release cycle ([b82a232e](EOLE/infra/ci-tools@b82a232e))
* **gitlab-ci:** automatic release creation with semantic-release ([df922909](EOLE/infra/ci-tools@df922909))
* **rules:** we prefer release naming over production status ([b7c0cd0e](EOLE/infra/ci-tools@b7c0cd0e))

feat(docker): build and tag images during developpment cycle

See merge request !10

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`

feat(gitlab-ci): automatic release creation with semantic-release

See merge request !9

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`.

feat(rules): we prefer release naming over production status

See merge request !8

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

ci(rules): define git-flow style rules

See merge request !7

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.

ci(commitlint): master is not always the repository default branch

See merge request !6

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

ci(gitlab-ci): split in reusable templates

See merge request !5

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.

ci(gitlab): add commit lint and its documentation

See merge request !2

* .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.

ci(codeowners): define @EOLE group members as owners

See merge request !3

This permit to notify the group for reviewing merge requests.