Repositories API

When generating a changelog for a range, GitLab ignores commits both added and reverted in that range. Revert commits themselves are included if they use the Git trailer used for generating changelogs.

Imagine the following scenario: you have three commits: A, B, and C. To generate changelogs, you use the default trailer Changelog. Both A and B use this trailer. Commit C is a commit that reverts commit B. When generating a changelog for this range, GitLab only includes commit A.

Revert commits are detected by looking for commits where the message contains the pattern This reverts commit SHA, where SHA is the SHA of the commit that is reverted.

If a revert commit includes the trailer used for generating changelogs (Changelog in the above example), the revert commit itself is included.

Customize the changelog output

The output is customized using a YAML configuration file stored in your project’s Git repository. This file must reside in .gitlab/changelog_config.yml.

You can set the following variables in this file:

• date_format: the date format to use in the title of the newly added changelog data. This uses regular strftime formatting.
• template: a custom template to use for generating the changelog data.
• categories: a hash that maps raw category names to the names to use in the changelog.
• include_groups: a list of group full paths containing users whose contributions should be credited regardless of project membership. The user generating the changelog must have access to each group or the members will not be credited.

Using the default settings, generating a changelog results in a section along the lines of the following:

## 1.0.0 (2021-01-05)

### Features (4 changes)

- [Feature 1](gitlab-org/gitlab@123abc) by @alice ([merge request](gitlab-org/gitlab!123))
- [Feature 2](gitlab-org/gitlab@456abc) ([merge request](gitlab-org/gitlab!456))
- [Feature 3](gitlab-org/gitlab@234abc) by @steve
- [Feature 4](gitlab-org/gitlab@456)

Each section starts with a title that contains the version and release date. While the format of the date can be customized, the rest of the title can’t be changed. When adding a new section, GitLab parses these titles to determine where in the file the new section should be placed. GitLab sorts sections according to their versions, not their dates.

Each section can have categories, each with their corresponding changes. In the above example, “Features” is one such category. You can customize the format of these sections.

The section names are derived from the values of the Git trailer used to include or exclude commits.

For example, if the trailer to use is called Changelog, and its value is feature, then the commit is grouped in the feature category. The names of these raw values might differ from what you want to show in a changelog, you can remap them. Let’s say we use the Changelog trailer and developers use the following values: feature, bug, and performance.

You can remap these using the following YAML configuration file:

---
categories:
  feature: Features
  bug: Bug fixes
  performance: Performance improvements

When generating the changelog data, the category titles are then ### Features, ### Bug fixes, and ### Performance improvements.

Custom templates

The category sections are generated using a template. The default template is as follows:

{% if categories %}
{% each categories %}
### {{ title }} ({% if single_change %}1 change{% else %}{{ count }} changes{% end %})

{% each entries %}
- [{{ title }}]({{ commit.reference }})\
{% if author.credit %} by {{ author.reference }}{% end %}\
{% if merge_request %} ([merge request]({{ merge_request.reference }})){% end %}

{% end %}

{% end %}
{% else %}
No changes.
{% end %}

The {% ... %} tags are for statements, and {{ ... }} is used for printing data. Statements must be terminated using a {% end %} tag. Both the if and each statements require a single argument.

For example, if we have a variable valid, and we want to display “yes” when this value is true, and display “nope” otherwise. We can do so as follows:

{% if valid %}
yes
{% else %}
nope
{% end %}

The use of else is optional. A value is considered true when it’s a non-empty value or boolean true. Empty arrays and hashes are considered false.

Looping is done using each, and variables inside a loop are scoped to it. Referring to the current value in a loop is done using the variable tag {{ it }}. Other variables read their value from the current loop value. Take this template for example:

{% each users %}
{{name}}
{% end %}

Assuming users is an array of objects, each with a name field, this would then print the name of every user.

Using variable tags, you can access nested objects. For example, {{ users.0.name }} prints the name of the first user in the users variable.

If a line ends in a backslash, the next newline is ignored. This allows you to wrap code across multiple lines, without introducing unnecessary newlines in the Markdown output.

Tags that use {% and %} (known as expression tags) consume the newline that directly follows them, if any. This means that this:

---
{% if foo %}
bar
{% end %}
---

Compiles into this:

---
bar
---

Instead of this:

---

bar

---

You can specify a custom template in your configuration like so:

---
template: |
  {% if categories %}
  {% each categories %}
  ### {{ title }}

  {% each entries %}
  - [{{ title }}]({{ commit.reference }})\
  {% if author.credit %} by {{ author.reference }}{% end %}

  {% end %}

  {% end %}
  {% else %}
  No changes.
  {% end %}

When specifying the template you should use template: | and not template: >, as the latter doesn’t preserve newlines in the template.

Template data

At the top level, the following variable is available:

• categories: an array of objects, one for every changelog category.

In a category, the following variables are available:

• title: the title of the category (after it has been remapped).
• count: the number of entries in this category.
• single_change: a boolean that indicates if there is only one change (true), or multiple changes (false).
• entries: the entries that belong to this category.

In an entry, the following variables are available (here foo.bar means that bar is a sub-field of foo):

• title: the title of the changelog entry (this is the commit title).
• commit.reference: a reference to the commit, for example, gitlab-org/gitlab@0a4cdd86ab31748ba6dac0f69a8653f206e5cfc7.
• commit.trailers: an object containing all the Git trailers that were present in the commit body.
• author.reference: a reference to the commit author (for example, @alice).
• author.contributor: a boolean set to true when the author is not a project member, otherwise false.
• author.credit: a boolean set to true when author.contributor is true or when include_groups is configured, and the author is a member of one of the groups.
• merge_request.reference: a reference to the merge request that first introduced the change (for example, gitlab-org/gitlab!50063).

The author and merge_request objects might not be present if the data couldn’t be determined. For example, when a commit is created without a corresponding merge request, no merge request is displayed.

Customize the tag format when extracting versions

^v?(?P<major>0|[1-9]\d*)\.(?P<minor>0|[1-9]\d*)\.(?P<patch>0|[1-9]\d*)(?:-(?P<pre>(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P<meta>[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$

This regular expression is based on the official v.

If your project uses a different format for tags, you can specify a different regular expression. The regular expression used must produce the following capture groups. If any of these capture groups are missing, the tag is ignored:

• major
• minor
• patch

---
tag_regex: '^version-(?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)$'

To test if your regular expression is working, you can use websites such as Generate changelog data

GET /projects/:id/repository/changelog

curl --header "PRIVATE-TOKEN: token" "https://gitlab.com/api/v4/projects/42/repository/changelog?version=1.0.0"

{
  "notes": "## 1.0.0 (2021-11-17)\n\n### feature (2 changes)\n\n- [Title 2](namespace13/project13@ad608eb642124f5b3944ac0ac772fecaf570a6bf) ([merge request](namespace13/project13!2))\n- [Title 1](namespace13/project13@3c6b80ff7034fa0d585314e1571cc780596ce3c8) ([merge request](namespace13/project13!1))\n"
}