diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index c0eb1d5dacc8199151dc291d0c256b7a54443869..144c2a12886f8e9421333e1a2a87dae67d84499b 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -43,6 +43,12 @@ stages:
   - deploy
   - release
 
+update changelog:
+  stage: build
+  script:
+    - curl -X POST "https://gitlab.mpcdf.mpg.de/api/v4/projects/$CI_PROJECT_ID/repository/changelog?version=${CI_COMMIT_TAG:1}&access_token=$CI_ACCESS_TOKEN&message=Add%20changelog%20for%20version%20$CI_COMMIT_TAG%20%5Bskip-ci%5D"
+  rules:
+    - if: $CI_COMMIT_TAG =~ /^v\d+\.\d+\.\d+$/
 
 build:
   stage: build
@@ -65,7 +71,6 @@ build:
       when: never
     - when: on_success
 
-
 python linting:
   stage: test
   image: ${CI_REGISTRY_IMAGE}/dev_python:${DOCKER_TAG}
diff --git a/CHANGELOG.md b/CHANGELOG.md
new file mode 100644
index 0000000000000000000000000000000000000000..5eac29e94115a57e6a6ebd577a3bae459e615a7f
--- /dev/null
+++ b/CHANGELOG.md
@@ -0,0 +1,13 @@
+## v1.1.6 (2022-12-23)
+
+### fixed (1 change)
+
+- [Fixed failing plot annotation valiation.](nomad-lab/nomad-FAIR@3cd5d0635566d9882e1c44cd922e113dfbeb1292) ([merge request](nomad-lab/nomad-FAIR!1005))
+
+### feature (1 change)
+
+- [Added a way to define formal models for metainfo annotations.](nomad-lab/nomad-FAIR@6a84b55e17dd5cd41cb5ba571f2451d528dbe6a0) ([merge request](nomad-lab/nomad-FAIR!990))
+
+### added (1 change)
+
+- [Replaced config object with pydantic models.](nomad-lab/nomad-FAIR@b9c1e023d95d14fd337b98a7ac895f505d4715a9) ([merge request](nomad-lab/nomad-FAIR!981))
diff --git a/README.md b/README.md
index c0791d629035f98a70330c85032bd8a3b2ef96c8..f505f0fe8776fe05580489110f8dcf3ab6af885a 100644
--- a/README.md
+++ b/README.md
@@ -13,7 +13,7 @@ standards like the [Optimade](http://www.optimade.org/) API.
 Furthermore, this projects aims at establishing NOMAD as a distributed platform for
 material science data sharing and management. This includes the on-site deployment of
 NOMAD as a standalone service (*oasis*), the federated use of NOMAD through a
-serious of full and partial *mirrors*.
+series of full and partial *mirrors*.
 
 ## Getting started
 
@@ -41,7 +41,9 @@ contributing, and API reference.
 
 ## Change log
 
-Omitted versions are plain bugfix releases with only minor changes and fixes.
+Omitted versions are plain bugfix releases with only minor changes and fixes. The
+file `CHANGELOG.md` might contain more detailed change information for the latest
+versions.
 
 ### v1.1.6
 - application dashboards with solar cell as an example
diff --git a/docs/develop/gitlab.md b/docs/develop/gitlab.md
index c2d904422c75c7b5b601f954dc5a26f0dfbda047..3457afce65e196234302d2b7c40744217a07f872 100644
--- a/docs/develop/gitlab.md
+++ b/docs/develop/gitlab.md
@@ -65,6 +65,11 @@ to run. The solution can be discussed in the merge request.
 ### Code review and merge
 
 When you are satisfied with your solution, and your CI/CD pipeline passes you can mark your MR as *ready*.
+Make sure that the `delete` option is checked to automatically remove you branch after
+merge. In most cases you should also check `squash` commits. This will replace all the
+commits in the MR with a single *squash* commit. If you do not want to *squash* your
+branch, make sure that you produce a reasonable and [clean version history](#clean-version-history).
+
 To review GUI changes, you should deploy your branch to the dev-cluster via CI/CD actions.
 Find someone on the NOMAD developer team to review your MR and request a review through
 GitLab. The review should be performed shortly and should not stall the MR longer than
@@ -75,6 +80,40 @@ threads are resolved, you can re-request a review. The reviewer should eventuall
 the MR. Typically we squash MRs to keep the revision history short.
 This will typically auto-close the issue.
 
+## Changelog
+
+We have an automatically generated changelog in the repository file `CHANGELOG.md`.
+This changelog is produced from commit messages and to maintain this file, you
+need to write commit messages accordingly.
+
+To trigger a changelog entry, your commit needs to end with a so called *git trailer*
+called `Changelog`. A typical commit message for a changelog entry should look like this:
+
+```
+A brief one line title of the change.
+
+A longer *markdown* formatted description of the change. Keep in mind that gitlab
+will automatically link the changelog entry with this commit and a respective merge
+requests. You do not need to manually link to any gitlab resources.
+
+This could span multiple paragraphs. However, keep it short. Documentation should
+go into the actual documentation, but you should mention breaks in backward compatibility,
+deprecation of features, etc.
+
+Changelog: Fixed
+```
+
+The trailer value (`Fixed` in the example) has to be one of the following values:
+
+- `Fixed`, for bugfixes.
+- `Added`, for new features.
+- `Changed`, for general improvements, e.g. updated documentation, refactoring,
+improving performance, etc.
+
+These categories are consistent with (keepachangelog.com)[https://keepachangelog.com/].
+For more information about the changelog generation read the [gitlab documentation](https://docs.gitlab.com/ee/api/repositories.html#add-changelog-data-to-a-changelog-file).
+
+
 ## Clean version history
 
 It is often necessary to consider code history to reason about potential problems in