## [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 !15

Prepare a release to support apps.education projects

See merge request !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 !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))

feat(semantic-release): use the image build by CI itself

See merge request !11

* templates/Release/Semantic-release.yaml: use
  `semantic-release-gitlab` image.

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