orhun / git-cliff Goto Github PK
View Code? Open in Web Editor NEWA highly customizable Changelog Generator that follows Conventional Commit specifications ⛰️
Home Page: https://git-cliff.org
License: Apache License 2.0
A highly customizable Changelog Generator that follows Conventional Commit specifications ⛰️
Home Page: https://git-cliff.org
License: Apache License 2.0
Thank you for creating a great tool.
I'm sorry if the behavior this is a specification.
Describe the bug
The global configuration file has the highest priority.
Is this the expected behavior?
Load the global configuration file even if cliff.toml
is in the current directory.
To Reproduce
cliff.toml
)~/.config/git-cliff/cliff.toml
)--config
(config.toml
)git cliff
git cliff --config config.toml
Expected behavior
This is an environment with a global configuration file.
git cliff
cliff.toml
exists in the current directory:: Load cliff.toml
in the current directory.cliff.toml
does not exists in the current directory:: Load global configuration.git cliff --config <PATH>
<PATH>
exists:: Load <PATH>
.<PATH>
does not exist:: Load embedded default configuration file into the binary.Screenshots/Logs
Check the file exists & Check diff
$ ls
cliff.toml config.toml
$ diff cliff.toml config.toml
6c6
< # local config
---
> # config option
27c27
< <!-- local config -->
---
> <!-- config option -->
$ diff cliff.toml ~/.config/git-cliff/cliff.toml
6c6
< # local config
---
> # global config
27c27
< <!-- local config -->
---
> <!-- global config -->
A global configuration file exists
$ git cliff
# global config
## [unreleased]
### Miscellaneous Tasks
- Add git-cliff toml
<!-- global config -->
$ git cliff --config config.toml
# global config
## [unreleased]
### Miscellaneous Tasks
- Add git-cliff toml
<!-- global config -->
A global configuration file does not exist
$ rm ~/.config/git-cliff/cliff.toml
$ git cliff
# local config
## [unreleased]
### Miscellaneous Tasks
- Add git-cliff toml
<!-- local config -->
$ git cliff --config config.toml
# config option
## [unreleased]
### Miscellaneous Tasks
- Add git-cliff toml
<!-- config option -->
System (please complete the following information):
Additional context
Current Behavior
This is an environment with a global configuration file.
git cliff
cliff.toml
exists in the current directory:: Load global configuration file.cliff.toml
does not exists in the current directory:: Load global configuration file.git cliff --config <PATH>
<PATH>
exists:: Load global configuration file.<PATH>
does not exist:: Load global configuration file.References
Thank you.
Describe the bug
In the Mission Pinball Framework we tag our commits as v0.56-dev.0
for development releases. Unfortunately, in git cliff
those show up as 0.56-de.0
(notice the missing v
).
Is there any guide how to change the tag regex? Standard perl syntax does not seem to work.
To Reproduce
git cliff
Expected behavior
I would like cliff to show 0.56-dev.0
in the headline instead of 0.56-de.0
.
Screenshots/Logs
## [0.56-de.0] - 2021-07-25
Describe the bug
If skip_tags
is defined with a regex that correctly generates the changelog (by skipping the correct/defined ones), there is a regression when setting previous
and using --latest
which was supposed to be fixed here: #3
But it looks like if you use --latest
in combination with skip_tags
, even if the pattern should not match the tag at all, it will simply not populate the previous
field. This might have been introduced here(?): 7f867ae
If I remove the skip_tags
from the config while generating with --latest
, previous
is populated as expected.
To Reproduce
Steps to reproduce the behavior:
[changelog]
header = """
# Changelog
All notable changes to this project will be documented in this file.\n
"""
body = """
{% if version %}\
# [{{ version | trim_start_matches(pat="v") }}]\
{% if previous %}\
{% if previous.version %}\
(https://github.com/discordjs/discord.js/compare/{{ previous.version }}...{{ version }})\
{% else %}
(https://github.com/discordjs/discord.js/tree/{{ version }}\
{% endif %}\
{% endif %} \
- ({{ timestamp | date(format="%Y-%m-%d") }})
{% else %}\
# [unreleased]
{% endif %}\
{% for group, commits in commits | group_by(attribute="group") %}
## {{ group | upper_first }}
{% for commit in commits %}
- {% if commit.breaking %}\
[**breaking**] \
{% endif %}\
{% if commit.scope %}\
**{{commit.scope}}:** \
{% endif %}\
{{ commit.message | upper_first }} ([{{ commit.id | truncate(length=7, end="") }}](https://github.com/discordjs/discord.js/commit/{{ commit.id }}))\
{% endfor %}
{% endfor %}\n
"""
trim = true
footer = ""
[git]
conventional_commits = true
filter_unconventional = true
tag_pattern = "[0-9]*"
skip_tags = "v[0-9]*|11|12"
ignore_tags = ""
All tags on the repo in question:
10.0.0
10.0.1
11.0.0
11.1.0
11.2.0
11.3.0
11.3.1
11.3.2
11.4.0
11.4.1
11.4.2
11.5.0
11.5.1
11.6.0
11.6.1
11.6.2
11.6.3
11.6.4
12.0.0
12.0.1
12.0.2
12.1.0
12.1.1
12.2.0
12.3.0
12.3.1
12.4.0
12.4.1
12.5.0
12.5.1
12.5.2
12.5.3
13.0.0
13.0.1
13.1.0
13.2.0
13.3.0
13.3.1
13.4.0
13.5.0
5.2.0
5.3.2
6.0.0
6.1.0
7.0.0
7.0.1
8.0.0
8.1.0
8.2.0
9.0.2
9.1.0
9.1.1
9.2.0
9.3.0
9.3.1
v5.0.0
v5.0.1
v5.1.0
v5.3.0
v5.3.1
Expected behavior
Expect skip_tags
to not drop unrelated tags from the previous
field.
System (please complete the following information):
It's possible I've missed it somewhere, but I cannot find where you've identified the key used to sign your release tarballs. gpg
identifies the signature as having been made by key 1D2D410A741137EBC544826F4A92FA17B6619297
, but aside from that key sharing a name with this project, I have no way of knowing whether I should trust it.
Describe the solution you'd like
Identify the key fingerprint in your readme. Better yet, sign/trust your signing key with Orhun's key, 165E0FF7C48C226E1EC363A7F83424824B3E4B90
, which is identified on their github profile.
Additional context
Having signatures for your Docker images would be nice as well.
Apologies if you've already put this somewhere and I've missed it!
Is your feature request related to a problem? Please describe.
We use conventinal commits and make use of footers to link to external systems.
It would be nice to have the possibility to proccess these footers and transform them into links.
These links can then be included in the changelog entry so that readers of the changelog can just click them
to get to the linked item.
Given the following example commit:
fix(db): use correct schema relation
Detailed decription...
Fixes: #123
Fixes: workitem 456
Refs: RFC1234
I would like to generate the following changelog entry:
Describe the solution you'd like
I think the most flexible way would be to have an additional custom tera filters available that can be applied to each footer value during template processing.
{% for footer in footers %}
{{ footer | into_links }}
{% endfor %}
The behaviour of into links would be configured in the config file as a series of replace patterns.
Describe alternatives you've considered
The following are alternatives I have tought off:
regex_replace
in tera, as proposed in #14, could most probably solve the issue.Describe the bug
Fails to parse conventional commit messages made from squashing and merging Pull Requests if there is no body message.
To Reproduce
Steps to reproduce the behavior:
TRACE
messages and the missing commits from the changelogExpected behavior
These PR commit messages can be parsed as normal
Screenshots/Logs
I did these steps on a fork of this repo: https://github.com/mjhipp/git-cliff
Created pull requests, and merged them:
one of them I added an extra message:
The git log:
Then tried to create a changelog:
It is not the parenthesis or #
, because it works if I commit directly:
If I perform an interactive rebase and "reword" the commits, without actually changing anything, the commits can then be parsed:
System (please complete the following information):
ubuntu-latest
for git-cliff-action
0.1.0
and git-cliff-action@v1
Additional context
Sorry for the long post! This is a great tool and I would really like to be able to use it with squashed PRs!
Describe the bug
When the commit-graph is like the following, the --current
option doesn't work correctly.
The tags
variable was like this.
However, the current code uses current_tag_index - 1
for the previous tag.
git-cliff/git-cliff/src/lib.rs
Line 169 in 848d8a5
I think we should find the nearest parent tag here.
To Reproduce
I attached my test scripts and the output.
Please save this script and run it.
#!/bin/bash
set -e
# Set up repository
rm -rf /tmp/test
mkdir -p /tmp/test
cd /tmp/test
git init
git commit --allow-empty -m "Initial commit"
# Create tags
git commit --allow-empty -m "feat: v0.1.0"
git tag v0.1.0
sleep 1
git checkout v0.1.0
git commit --allow-empty -m "feat: v0.2.0"
git tag v0.2.0
sleep 1
git checkout v0.1.0
git commit --allow-empty -m "fix: v0.1.1"
git tag v0.1.1
sleep 1
git checkout v0.2.0
git commit --allow-empty -m "feat: v0.3.0"
git tag v0.3.0
sleep 1
# Show results
git checkout v0.1.0
echo "------"
echo "v0.1.0"
git-cliff --current
echo "------"
git checkout v0.1.1
echo "------"
echo "v0.1.1"
git-cliff --current
echo "------"
git checkout v0.2.0
echo "------"
echo "v0.2.0"
git-cliff --current
echo "------"
git checkout v0.3.0
echo "------"
echo "v0.3.0"
git-cliff --current
echo "------"
Without sleep
, probably because the commit timestamp will be the same and it won't reproduce the problem.
$ ./test.sh
Initialized empty Git repository in /tmp/test/.git/
[main (root-commit) 228dbab] Initial commit
[main 7d5b9fb] feat: v0.1.0
Note: switching to 'v0.1.0'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
git switch -c <new-branch-name>
Or undo this operation with:
git switch -
Turn off this advice by setting config variable advice.detachedHead to false
HEAD is now at 7d5b9fb feat: v0.1.0
[detached HEAD ee77516] feat: v0.2.0
Previous HEAD position was ee77516 feat: v0.2.0
HEAD is now at 7d5b9fb feat: v0.1.0
[detached HEAD 44cfc20] fix: v0.1.1
Previous HEAD position was 44cfc20 fix: v0.1.1
HEAD is now at ee77516 feat: v0.2.0
[detached HEAD 567de7b] feat: v0.3.0
Previous HEAD position was 567de7b feat: v0.3.0
HEAD is now at 7d5b9fb feat: v0.1.0
------
v0.1.0
WARN git_cliff > "cliff.toml" is not found, using the default configuration.
# Changelog
All notable changes to this project will be documented in this file.
## [0.1.0] - 2022-01-30
### Features
- V0.1.0
<!-- generated by git-cliff -->
------
Previous HEAD position was 7d5b9fb feat: v0.1.0
HEAD is now at 44cfc20 fix: v0.1.1
------
v0.1.1
WARN git_cliff > "cliff.toml" is not found, using the default configuration.
# Changelog
All notable changes to this project will be documented in this file.
## [0.1.1] - 2022-01-30
### Bug Fixes
- V0.1.1
<!-- generated by git-cliff -->
------
Previous HEAD position was 44cfc20 fix: v0.1.1
HEAD is now at ee77516 feat: v0.2.0
------
v0.2.0
WARN git_cliff > "cliff.toml" is not found, using the default configuration.
# Changelog
All notable changes to this project will be documented in this file.
## [0.2.0] - 2022-01-30
### Features
- V0.2.0
<!-- generated by git-cliff -->
------
Previous HEAD position was ee77516 feat: v0.2.0
HEAD is now at 567de7b feat: v0.3.0
------
v0.3.0
WARN git_cliff > "cliff.toml" is not found, using the default configuration.
# Changelog
All notable changes to this project will be documented in this file.
## [0.3.0] - 2022-01-30
### Features
- V0.3.0
## [0.2.0] - 2022-01-30
### Features
- V0.2.0
<!-- generated by git-cliff -->
------
0.2.0
is included in 0.3.0
.
## [0.3.0] - 2022-01-30
### Features
- V0.3.0
## [0.2.0] - 2022-01-30
### Features
- V0.2.0
Expected behavior
The output only includes the tag's changes.
In this case:
## [0.3.0] - 2022-01-30
### Features
- V0.3.0
Is your feature request related to a problem? Please describe.
Our CI system prepends all changes which are merged by using the PR functionality (by policy everyone has to do so) with "Merged PR xxx: ". This does not comply with the conventional commit message format.
Describe the solution you'd like
Something like a commit message preprocessor which enables us to remove or select certain parts of the commit message/body to be used in the following processes.
Describe alternatives you've considered
Removing that prefix, which is unfortunately not possible.
Hi,
In the context of a mono-repo, is it possible to specify the repository subpath to build the changelog from ?
Something like git cliff -- subpath/
Thanks.
Is your feature request related to a problem? Please describe.
Currently, --latest
option is supported, but it's a bit difficult to use.
Suppose this situation:
v0.10.0-test
is releasedv0.11.0-test
is releasedv0.10.1-test
is releasedThen the current behaviors are:
$ git checkout v0.10.0-test
$ git cliff | head
# Changelog
All notable changes to this project will be documented in this file.
## [0.10.0-test] - 2021-11-28
### Features
- Add A
## [0.9.0-test] - 2021-11-25
$ git cliff --latest
# Changelog
All notable changes to this project will be documented in this file.
## [0.10.1-test] - 2021-11-28
### Bug Fixes
- Fix A
<!-- generated by git-cliff -->
$ git checkout v0.11.0-test
$ git cliff | head
# Changelog
All notable changes to this project will be documented in this file.
## [0.11.0-test] - 2021-11-28
### Features
- Add B
## [0.10.0-test] - 2021-11-28
$ git cliff --latest
# Changelog
All notable changes to this project will be documented in this file.
## [0.10.1-test] - 2021-11-28
### Bug Fixes
- Fix A
<!-- generated by git-cliff -->
$ git checkout v0.10.1-test
$ git cliff | head
# Changelog
All notable changes to this project will be documented in this file.
## [0.10.1-test] - 2021-11-28
### Bug Fixes
- Fix A
## [0.10.0-test] - 2021-11-28
$ git cliff --latest
# Changelog
All notable changes to this project will be documented in this file.
## [0.10.1-test] - 2021-11-28
### Bug Fixes
- Fix A
<!-- generated by git-cliff -->
I want an option that extracts commits that are in only one release based on the current branch, but I guess there is nothing like that.
I believe it's useful for generating the body for GitHub Releases like you show here.
Currently, you use --latest
for this, but since what --latest
points to will change, it's difficult to use correctly.
Describe the solution you'd like
A clear and concise description of what you want to happen.
I guess adding --current
option can solve this problem.
It behaves like this:
$ git checkout v0.10.0-test
$ git cliff --current
# Changelog
All notable changes to this project will be documented in this file.
## [0.10.0-test] - 2021-11-28
### Features
- Add A
<!-- generated by git-cliff -->
$ git checkout v0.11.0-test
$ git cliff --current
# Changelog
All notable changes to this project will be documented in this file.
## [0.11.0-test] - 2021-11-28
### Features
- Add B
<!-- generated by git-cliff -->
$ git checkout v0.10.1-test
$ git cliff --current
# Changelog
All notable changes to this project will be documented in this file.
## [0.10.1-test] - 2021-11-28
### Bug Fixes
- Fix A
<!-- generated by git-cliff -->
Describe alternatives you've considered
Extracting the section of the current release using some text processing tools can achieve the same thing, but it's a bit troublesome.
Additional context
If I switch the order of creating tags, for example v0.11.0-test
after v0.10.1-test
, --latest
will point to v0.11.0-test
, so I feel it's hard to estimate.
Is your feature request related to a problem? Please describe.
I cannot iterate over commits that are missing a scope.
According to the Tera docs of group-by, items that lack an attribute are discarded.
This means that if I want to have a scoped changelog, as per the git-cliff example, (and I do) then these commits are skipped from the changelog.
Describe the solution you'd like
I would like git-cliff
to mark these commits in a specially named scope (maybe called unscoped
? maybe have it configurable?) so I can iterate over them in my template and create a special section/heading for them
Describe alternatives you've considered
If git-cliff does not somehow mark these missing scopes, I do not believe there is an alternative on iterating over them.
Additional context
Some capture of the output of git-clif when scopes are missing:
# Changelog
All notable changes to this project will be documented in this file.
## [unreleased]
### Documentation
### Infrastructure
#### Ide
- Added git commit hooks for conventional messages
- Added suggested VS Code extensions
<!-- generated by git-cliff -->
Note the Documentation section that does not display any commits there (since the commit message is like docs: some commit message
Describe the bug
Cannot install git-cliff from crates-io due to missing config
folder.
Hunch: If the build process requires the config
folder, it must be specified to be included to via a cargo manifest key https://doc.rust-lang.org/cargo/reference/manifest.html#the-exclude-and-include-fields (note that you need to specify everything to include then, the globs need to be added explicitly).
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Build and install the binary.
Screenshots/Logs
Compiling git-cliff-core v0.2.3
error: proc-macro derive panicked
--> /home/bernhard/.cargo/registry/src/github.com-1ecc6299db9ec823/git-cliff-core-0.2.3/src/embed.rs:16:17
|
16 | #[derive(Debug, RustEmbed)]
| ^^^^^^^^^
|
= help: message: #[derive(RustEmbed)] folder '/home/bernhard/.cargo/registry/src/github.com-1ecc6299db9ec823/git-cliff-core-0.2.3/../config/' does not exist. cwd: '/home/bernhard/.cargo/registry/src/github.com-1ecc6299db9ec823/git-cliff-core-0.2.3'
error[E0599]: no function or associated item named `get` found for struct `EmbeddedConfig` in the current scope
--> /home/bernhard/.cargo/registry/src/github.com-1ecc6299db9ec823/git-cliff-core-0.2.3/src/embed.rs:23:15
|
18 | pub struct EmbeddedConfig;
| -------------------------- function or associated item `get` not found for this
...
23 | match Self::get(crate::DEFAULT_CONFIG) {
| ^^^ function or associated item not found in `EmbeddedConfig`
|
= help: items from traits can only be used if the trait is implemented and in scope
= note: the following traits define an item `get`, perhaps you need to implement one of them:
candidate #1: `SliceIndex`
candidate #2: `bitvec::slice::api::BitSliceIndex`
candidate #3: `lexical_core::util::sequence::SliceLike`
candidate #4: `RustEmbed`
error: aborting due to 2 previous errors
System (please complete the following information):
Describe the solution you'd like
I'd love to automate generation of Changelog that's presented on serverless project, which:
Is that possible with git-cliff?
I'm sorry if the behavior this is a specification.
Describe the bug
Skip all tags, when skip_tags = ""
.
Is this the expected behavior?
To Reproduce
I've created a test script.
#!/bin/bash
set -e
rm -rf /tmp/cliff/skip_tags_test
mkdir -p /tmp/cliff/skip_tags_test
cd /tmp/cliff/skip_tags_test
git init
git commit --allow-empty -m "chore: v0.0.1"
git tag v0.0.1
git commit --allow-empty -m "feat: v0.1.0-beta.1"
git tag v0.1.0-beta.1
git commit --allow-empty -m "feat: v0.1.0"
git tag v0.1.0
git cliff --init
echo '====================================='
echo 'skip_tags = "v0.1.0-beta.1" (Default)'
echo '====================================='
git cliff
sed -i 's/\(skip_tags = \)"v0.1.0-beta.1"/\1""/' cliff.toml
echo '====================================='
echo 'skip_tags = ""'
echo '====================================='
git cliff
sed -i 's/skip_tags.*//' cliff.toml
echo '====================================='
echo 'skip_tags is unset.'
echo '====================================='
git cliff
Initialized empty Git repository in /tmp/cliff/skip_tags_test/.git/
[main (root-commit) c57e04c] chore: v0.0.1
[main fe30e5e] feat: v0.1.0-beta.1
[main 9492956] feat: v0.1.0
INFO git_cliff > Saving the configuration file to "cliff.toml"
=====================================
skip_tags = "v0.1.0-beta.1" (Default)
=====================================
# Changelog
All notable changes to this project will be documented in this file.
## [0.1.0] - 2022-02-19
### Features
- V0.1.0
## [0.0.1] - 2022-02-19
### Miscellaneous Tasks
- V0.0.1
<!-- generated by git-cliff -->
=====================================
skip_tags = ""
=====================================
# Changelog
All notable changes to this project will be documented in this file.
<!-- generated by git-cliff -->
=====================================
skip_tags is unset.
=====================================
# Changelog
All notable changes to this project will be documented in this file.
## [0.1.0] - 2022-02-19
### Features
- V0.1.0
## [0.1.0-beta.1] - 2022-02-19
### Features
- V0.1.0-beta.1
## [0.0.1] - 2022-02-19
### Miscellaneous Tasks
- V0.0.1
<!-- generated by git-cliff -->
skip_tags = ""
# Changelog
All notable changes to this project will be documented in this file.
<!-- generated by git-cliff -->
Expected behavior
I expect don't skip all tags, as when skip_tags
is unset.
skip_tags
is unset.
# Changelog
All notable changes to this project will be documented in this file.
## [0.1.0] - 2022-02-19
### Features
- V0.1.0
## [0.1.0-beta.1] - 2022-02-19
### Features
- V0.1.0-beta.1
## [0.0.1] - 2022-02-19
### Miscellaneous Tasks
- V0.0.1
<!-- generated by git-cliff -->
System (please complete the following information):
Additional context
Code that may be relevant.
git-cliff/git-cliff/src/lib.rs
Lines 124 to 130 in 761669e
I have changed to the following code.
let skip = skip_regex.map(|r| r.is_match(name)).unwrap_or_default();
println!("{}", skip);
println!("{}", skip);
output true
always, when skip_tags = ""
.
Thank you.
Is your feature request related to a problem? Please describe.
Is not a problem, but is easier to share cliff.toml
with all required config than share the file and ask people to pass the sort parameter when run.
It could be interesting supports multiple matches into the same no conventional commit message.
For example, on the same commit:
Summary of my commit
new: added something amazing
fix: solved problem
refactor: i've rewritten an entire class
git cliff should generate relative group for each match (Features, Bug Fix, Refactor etc.)
Describe the bug
A clear and concise description of what the bug is.
When commit scope is (*)
or *
it isn't generated
To Reproduce
Steps to reproduce the behavior:
feat(*): user authentication
Expected behavior
the item get added with default_scope and to be treated as if it's feat: user authentication
System (please complete the following information):
Additional context
cliff configuration: https://gist.github.com/tami5/1044c256a173c622847114cc3bcd0ffd
Is your feature request related to a problem? Please describe.
If my repository contains submodules and I have commits updating the submodule, I only see the a commit doing the update.
The information what changed in the submodule is not visible.
If the submodule also follow the same commit convention I would like to have a way to also include the submodule commits in my changelog.
Describe the solution you'd like
Add an option to recurse into submodules.
With this option enabled, git-cliff would, whenever it encounters a commit changing a submodule revision, recurse into this submodule.
It would then get the list of all commits included in this version change and include them in the current changelog. Maybe separated by submodule to allow nicely group them in the output.
Describe alternatives you've considered
Describe the bug
When running it on https://github.com/torvalds/linux with the cliff.toml from this repository, the git-cliff
process will take a lot of time and consume more and more memory. I had to stop it at 12GB.
To Reproduce
Steps to reproduce the behavior:
git clone https://github.com/torvalds/linux
cp cliff.toml ./linux/
cd linux
git cliff
Expected behavior
A log is produced in reasonable time.
System (please complete the following information):
Ran f1b495d on MacOS with 8GB of RAM and M1
Is your feature request related to a problem? Please describe.
While testing this tool, I felt the skip_tags
option behaves unnaturally.
The current behavior seems completely dropping commits from the changelog, but I believe that if a certain tag is skipped, it should be included in the next tag.
So for example, supposing the commits and tags are like the following and that skip_tags
is v0.2.0-beta.1
,
[v0.2.0] feat: add B
[v0.2.0-beta.1] fix: fix A
[v0.1.0] feat: add A
The current behavior is:
[v0.2.0]
## Feature
- Add B
[v0.1.0]
## Feature
- Add A
However, it should be:
[v0.2.0]
## Feature
- Add B
## Fix
- Fix A
[v0.1.0]
## Feature
- Add A
Describe the solution you'd like
Changing the behavior of skip_tags
can solve the problem, I believe.
This is an example of the implementation.
kenji-miyake@89d0bf4
How to test:
$ git clone [email protected]:kenji-miyake/git-cliff.git -b main
$ cd git-cliff
$ # Before
$ cargo run | grep -A 20 "0.1.0-beta.2"
Compiling git-cliff v0.4.2 (/tmp/git-cliff/git-cliff)
Finished dev [unoptimized + debuginfo] target(s) in 2.20s
Running `target/debug/git-cliff`
WARN git_cliff > "cliff.toml" is not found, using the default configuration.
## [0.1.0-beta.2] - 2021-06-14
### Bug Fixes
- Install musl-tools for musl builds
### Miscellaneous Tasks
- Update config
<!-- generated by git-cliff -->
$ # After
$ git checkout fix-skip-tags-behavior
$ cargo run | grep -A 20 "0.1.0-beta.2"
Finished dev [unoptimized + debuginfo] target(s) in 0.04s
Running `target/debug/git-cliff`
WARN git_cliff > "cliff.toml" is not found, using the default configuration.
## [0.1.0-beta.2] - 2021-06-14
### Bug Fixes
- Add timestamp field to Release structs
- Update tests about recent changes
- Update fields
- Require -u or -l flag for prepending changelog
- Write to the given file for prepend operation
- Install zlib dependency
- Install musl-tools for musl builds
### Documentation
- Add doc comment to GroupParser
- Add comments
- Add FUNDING.yml
- Add comments to struct fields
- Add doc comment to generate method
- Add comments to main
- Mention docker
Describe alternatives you've considered
Seeing your use case, it seems you'd like to drop commits before v0.1.0-beta.1
, which has a lot of commits.
Therefore, I guess it's nice to add another option like skip_before
or so.
Additional context
Since we can drop commits by setting skip = true
in commit_parsers
, I guess there is no problem with changing like this.
Is your feature request related to a problem? Please describe.
It would be nice to see an example in the documentation for the usage of git-cliff
with GitLab CI.
Describe the solution you'd like
Add an example .gitlab-ci.yml
to README.md, preferably after the github-action section.
Describe alternatives you've considered
None
Additional context
#20
Describe the bug
Running the command git cliff --prepend packages/discord.js/CHANGELOG.md -u --include-path 'packages/discord.js/*'
gives me absolutely nothing.
If I remove the include-path
it does, but then obviously commits that went into different packages are being thrown into that changelog too.
I do indeed run this command in each package git cliff --prepend ./CHANGELOG.md -l -c ../../cliff.toml -r ../../ --include-path './*'
which should be fine, but I also tried the one mentioned above, which also does not work.
If a repo is needed:
https://github.com/discordjs/discord.js
Running:
git cliff --unreleased --prepend packages/discord.js/CHANGELOG.md --include-path 'packages/discord.js/*'
OR:
cd packages/discord.js
git cliff --unreleased --prepend ./CHANGELOG.md -c ../../cliff.toml -r ../../ --include-path './*'
Will reproduce it, otherwise similar steps will most likely work too on any repo.
To Reproduce
[changelog]
header = """
# Changelog
All notable changes to this project will be documented in this file.\n
"""
body = """
{% if version %}\
# [{{ version | trim_start_matches(pat="v") }}]\
{% if previous %}\
{% if previous.version %}\
(https://github.com/discordjs/discord.js/compare/{{ previous.version }}...{{ version }})\
{% else %}
(https://github.com/discordjs/discord.js/tree/{{ version }})\
{% endif %}\
{% endif %} \
- ({{ timestamp | date(format="%Y-%m-%d") }})
{% else %}\
# [unreleased]
{% endif %}\
{% for group, commits in commits | group_by(attribute="group") %}
## {{ group | upper_first }}
{% for commit in commits %}
- {% if commit.breaking %}\
[**breaking**] \
{% endif %}\
{% if commit.scope %}\
**{{commit.scope}}:** \
{% endif %}\
{{ commit.message | upper_first }} ([{{ commit.id | truncate(length=7, end="") }}](https://github.com/discordjs/discord.js/commit/{{ commit.id }}))\
{% endfor %}
{% endfor %}\n
"""
trim = true
footer = ""
[git]
conventional_commits = true
filter_unconventional = true
commit_parsers = [
{ message = "^feat", group = "Features"},
{ message = "^fix", group = "Bug Fixes"},
{ message = "^docs", group = "Documentation"},
{ message = "^perf", group = "Performance"},
{ message = "^refactor", group = "Refactor"},
{ message = "^typings", group = "Typings"},
{ message = "^types", group = "Typings"},
{ message = ".*deprecated", body = ".*deprecated", group = "Deprecation"},
{ message = "^revert", skip = true},
{ message = "^style", group = "Styling"},
{ message = "^test", group = "Testing"},
{ message = "^chore", skip = true},
{ message = "^ci", skip = true},
{ message = "^build", skip = true},
{ body = ".*security", group = "Security"},
]
filter_commits = true
tag_pattern = "[0-9]*"
skip_tags = "v[0-9]*|11|12"
ignore_tags = ""
topo_order = false
sort_commits = "newest"
Expected behavior
Expect a changelog to be generated with only commits that target the specific folder and files mentioned in the --include-path
System (please complete the following information):
Hey, great project but was wondering if it is possible to perform regex replacements in values like commit messages.
Something like {{ commit.message | replace(from="#(\d+)", to="") }}
to turn Update dependencies (#57)
into Update dependencies
Describe the bug
I can't get cargo to update git-cliff to v0.4.0 (I'm on v0.3.0). I tried to uninstall and install again, but it fetches v0.3.0
To Reproduce
Steps to reproduce the behavior:
or
Expected behavior
I expect to be able to update or install the new version
Screenshots/Logs
error: could not find git-cliff
in registry crates-io
with version =0.4.0
System (please complete the following information):
Is your feature request related to a problem? Please describe.
The default configuration generates the changelog that violates a markdownlint
rule MD022.
If there are no reasons for this, I feel it would be nice to comply with MD022
.
Describe the solution you'd like
Just to add \n
after # Changelog
.
Before:
header = """
# Changelog
All notable changes to this project will be documented in this file.\n
"""
After:
header = """
# Changelog\n
All notable changes to this project will be documented in this file.\n
"""
Describe alternatives you've considered
Replace \n
with a newline.
header = """
# Changelog
All notable changes to this project will be documented in this file.\n
"""
Additional context
Nothing.
// offtopic: git-cliff is my favourite changelog generation tool after trying a lot of them. So thanks for that!
Describe the bug
When running git-cliff in the Gitlab CI. The tool results an IO error. Not sure where to go from here. Executing pwd
gives the correct path, that includes a .git
directory.
Expected behavior
It would run in the same way as it does locally.
System (please complete the following information):
Describe the bug
When using "latest" previous is not set.
To Reproduce
Steps to reproduce the behavior:
Notes: experienced on PurpleBooth/git-mit, it has the config as defined below.
[changelog]
header = """## Changelog
"""
body = """
{% if version %}\
{% if previous %}\
### [{{ version }}](https://github.com/PurpleBooth/git-mit/compare/{{ previous.version }}...{{ version }}) ({{ timestamp | date(format="%Y-%m-%d") }})
{% else %}\
### [{{ version }}](https://github.com/PurpleBooth/git-mit/tree/{{ version }}) ({{ timestamp | date(format="%Y-%m-%d") }})
{% endif %}\
{% else %}\
### [unreleased]
{% endif %}\
{% if previous %}\
{% if previous.commit_id %}
[{{ previous.commit_id | truncate(length=7, end="") }}]({{ previous.commit_id }})...\
[{{ commit_id | truncate(length=7, end="") }}]({{ commit_id }})
{% endif %}\
{% endif %}\
{% for group, commits in commits | group_by(attribute="group") %}
### {{ group | upper_first }}
{% for commit in commits %}
- {{ commit.message | upper_first }} ([{{ commit.id | truncate(length=7, end="") }}]({{ commit.id }}))\
{% endfor %}
{% endfor %}\n
"""
trim = true
[git]
conventional_commits = true
tag_pattern = "v[0-9]*"
Expected behavior
A clear and concise description of what you expected to happen.
I would expect previous to always be set, so we can correctly generate compare URLs for Github.
Screenshots/Logs
$ git-cliff | head
## Changelog
### [unreleased]
### Fix
- Update the changelog ([70bd7ff](70bd7ffe55857940e898f5b97b34b2f62acd1c8e))
### [v4.0.14](https://github.com/PurpleBooth/git-mit/compare/v4.0.13...v4.0.14) (2021-08-14)
[88ef7ec](88ef7ecd813d32f19804421acf3daa3e396d48e2)...[fb1afd9](fb1afd98c2c290fee748c89fde064667f49b8cda)
$ git-cliff --latest | head
## Changelog
### [v4.0.14](https://github.com/PurpleBooth/git-mit/compare/...v4.0.14) (2021-08-14)
### Build
- Versio update versions ([fb1afd9](fb1afd98c2c290fee748c89fde064667f49b8cda))
### Chore
- Update FUNDING.yml ([651ef61](651ef61ed10923c6e451bd63dae4b038c845ad2e))
System (please complete the following information):
$ sw_vers
ProductName: macOS
ProductVersion: 11.5.1
BuildVersion: 20G80
$ git-cliff --version
git-cliff 0.1.0
Additional context
Add any other context about the problem here.
First of all I really like the simplicty of git-cliff
, but I encountered an issue where I don't know, if we are using it correct or not. It sounds like a little bit like #29, but I'm not sure.
Description
In the project I'm working on we have a git-flow
like branching model at the moment. We created from develop the version v1.0.0 and merged these changes to master. Afterwards we continued our work on v1.1.0 on develop in the meanwhile, but later an urgent issue for v1.0.0 occured and we had to create an hotfix v1.0.1.
We created an branch hotfix/1.0.1 from master and merged these changes back to master and develop, but on develop the work continued and after the merge of hotfix/1.0.1 into develop the changelog now combines the changes from the hotfix with the unreleased changes on develop.
Actual Output
* 1473da8 (HEAD -> develop) Merge branch 'hotfix/1.0.1' into develop
|\
| * 6134a57 (tag: v1.0.1, master, hotfix/1.0.1) fix: v1.0.1
* | 5ce33a7 chore: start work on v1.1.0
|/
* a6915e6 (tag: v1.0.0) feat: v1.0.0
The corresponding changelog looks like this:
# Changelog
All notable changes to this project will be documented in this file.
## [1.0.1] - 2021-12-01
### Bug Fixes
- v1.0.1
### Miscellaneous Tasks
- Start work on v1.1.0
## [1.0.0] - 2021-11-01
### Features
- v1.0.0
Expected Output
# Changelog
All notable changes to this project will be documented in this file.
## [unreleased]
### Miscellaneous Tasks
- Start work on v1.1.0
## [1.0.1] - 2021-12-01
### Bug Fixes
- v1.0.1
## [1.0.0] - 2021-11-01
### Features
- v1.0.0
Question
How can we prevent that the hotfix changes an the unreleased changes are combined by their commit date?
Describe the bug
I set the Gitlab CI with the following stage
changelog:
image:
name: orhunp/git-cliff:latest
entrypoint: [""]
stage: doc
script:
- git-cliff
here is the result on Gitlab CI
I don't understand why it is not working.
I try to reproduce the error but impossible on a new repo :/
If you have any idea where it can come from
System (please complete the following information):
Describe the bug
Some conventional_commits
are not marked as conventional_commits
. We're using scopes with underscores and those commits are not seen as conventional. This is valid though: https://github.com/conventional-commits/parser#the-grammar
To Reproduce
Steps to reproduce the behavior:
feat(my_feature): add the new 'my' feature
conventional_commits
config setting is true.Expected behavior
It should be added as it's a valid conventional commit message.
System (please complete the following information):
Additional context
Add any other context about the problem here.
I think this problem occurs in the git-conventional
dependency. I also made an issue there:
crate-ci/git-conventional#17
Is your feature request related to a problem? Please describe.
A new release of git_conventionnal was just published who add breaking_description
Describe the solution you'd like
Add breaking_description to the available meta
Additional context
Could be used to generate Breaking Changes
section in template easily.
Is your feature request related to a problem? Please describe.
A man page should be added to the project for accessing the documentation using man(1)
:
$ man git-cliff
Describe the solution you'd like
Add a man page under docs/
in the root directory of the project. It should contain information about the command line arguments, configuration file sections/fields and the basic usage.
There are 2 possible ways that I can think of to achieve this:
docs/git-cliff.1
help2man(1)
can be used for assistance.Describe alternatives you've considered
None.
Additional context
None.
Hi, git-cliff
is cool stuff!
1. Is your feature request related to a problem? Please describe.
I'd like to not put cliff.toml
in my repository when I use git-cliff
just as an alternative to git log
.
2. Describe the solution you'd like
git-cliff
locates cliff.toml
in ~/.config/git-cliff/cliff.toml
. If no configuraiton file is found, git-cliff
uses default (builtin) configuration.
3. Describe alternatives you've considered
git-cliff
looks into GIT_CLIF_CONFIG
environment variable.
4. Additional context
Default configuration removes the need of copying cliff.toml
, so it would help first-time users.
Describe the bug
Tags which are on release branches and not on the default branch are ignored and the commits are marked as Unreleased. We are migrating to release branches at the moment and therefore there are tags on the main branch.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The git tags are included as versions in the changelog. The diff for the commits is done by comparing 2.3.4...6.5.4
System:
Is your feature request related to a problem? Please describe.
Sorry, I am not sure if this already doable and I missed it, but what I am interested in is to generate a changelog between two tags. But if the two tags contain other tags in between I do not want to see the inbetween tag versions.
The actual example is that if there are tags like:
v1.0.0. v1.1.0a1, v1.1.0b1, v1.1.0b2, v1.1.0
I might want to have changelogs for releases between v1.0.0
and v1.1.0a1
or v1.1.0a1
and v1.1.0b1
etc, but when I release the final v1.1.0
I want to create another changelog between v1.0.0
and v1.1.0
but without the intermediary tags (there might be a ton of them)
Describe the solution you'd like
I guess, a parameter that does not group by tags?
Additional context
Here is a dump of what git-cliff currently generates as changelog between two tags:
➜ git cliff v0.40..v0.45
# Changelog
All notable changes to this project will be documented in this file.
## [0.45] - 2021-05-26
### Infra
## [0.44] - 2021-05-24
### Feat
### Fix
## [0.43] - 2021-05-07
### Feat
### Fix
### Infra
## [0.42] - 2021-04-24
### BREAKING
### Feat
### Fix
## [0.41] - 2021-04-14
### BREAKING
<!-- generated by git-cliff -->
Describe the bug
Hey! I'm seeing some odd results when generating a changelog if the most recent tag (chronologically) is not in the same version line. I'm not sure if it's something I'm doing wrong... 🤔
To Reproduce
master
as follows (most recent on top, as per git log
:
feat: fifth commit on master
feat: fourth commit on master <-- tag v0.2.0
chore: third commit on master
fix: second commit on master <-- tag v0.1.0
feat: first commit on master
v0.1.x
line, so I checked out the tag, started a new branch and made a commit:
fix: patch on v0.1.x <-- tag v0.1.1
fix: second commit on master <-- tag v0.1.0
feat: first commit on master
v0.1.1
, I get the result I expected ("Patch on v0.1.x"), however the changelog for the unreleased commit on master is not:
# Changelog
All notable changes to this project will be documented in this file.
## [unreleased]
### Features
- Fifth commit on master
## [0.2.0] - 2021-10-22
### Features
- Fourth commit on master
### Miscellaneous Tasks
- Third commit on master
<!-- generated by git-cliff -->
git cliff v0.2.0..
instead does give me the expected result.Expected behavior
I expected the output of git cliff -u
to be the same as git cliff v0.2.0..
in this case:
# Changelog
All notable changes to this project will be documented in this file.
## [unreleased]
### Features
- Fifth commit on master
<!-- generated by git-cliff -->
If this is the intended behaviour, just let me know and I'll adapt our CI jobs to use the explicit git refspec. Thanks! 🤗
Describe the bug
As I was tweaking my cliff.toml
file to get the changelog to look exactly how I want it, I noticed the order of the groups is not affected by the elements in commit_parsers
, but rather seems to be alphabetical on the group name.
Expected behavior
I hoped the groups would appear in the markdown in the same order as the commit_parsers
array. Maybe there's a way to work around this? Thanks!
Is your feature request related to a problem? Please describe.
In a monorepo, I that have a folder with the name "www", however, since I am using git-cliff to generate a public-facing changelog, I would wish for this to be displayed as "Application" when generated.
I am using template replace functions to replace "www" with "Application" but would like the ability to change this in the commit_parsers
.
Describe the solution you'd like
commit_parsers
should allow changing of the scope on-demand. For example:
commit_parsers = [
{ message = "(www)", scope = "Application" }
]
Describe alternatives you've considered
N/A
Additional context
Thanks for an awesome project!
Describe the bug
commit_parsers.message
includes body in the search range.
Similarly, commit_parsers.body
includes message in the search range.
To Reproduce
git cliff
.Details about the commit log, commit_parses
, output CHANGELOG, etc. are described in "Screenshots/Logs".
Expected behavior
The search range of commit_parsers.message
is message only.
The search range of commit_parsers.body
is body only.
Screenshots/Logs
cliff.toml
[git]
conventional_commits = false
filter_unconventional = false
commit_parsers = [
{ message = "apple", group = "Apple"},
{ body = "banana", group = "Banana"},
]
The other values are default values.
git log
commit 469fba85058e6103ac1b892e4edde951f545ee0e (HEAD -> main)
Author: hituzi_no_sippo <[email protected]>
Date: Sun Jan 30 15:46:21 2022 +0900
banana
commit 61f0ea6765b321c7d23a7b2c31ed191c37dfbea3
Author: hituzi_no_sippo <[email protected]>
Date: Sun Jan 30 15:45:54 2022 +0900
camel
apple
commit 3a819db2bdb0917d3864998dab5858afc8fc8da2
Author: hituzi_no_sippo <[email protected]>
Date: Sun Jan 30 15:45:06 2022 +0900
apple
git cliff
# Changelog
All notable changes to this project will be documented in this file.
## [unreleased]
### Apple
- Apple
- Camel
apple
### Banana
- Banana
<!-- generated by git-cliff -->
There is no apple in the message of the Camel, but it is listed in CHANGELOG.
There is no banana in the body of the Banana, but it is listed in CHANGELOG.
Expected
# Changelog
All notable changes to this project will be documented in this file.
## [unreleased]
### Apple
- Apple
<!-- generated by git-cliff -->
System (please complete the following information):
Additional context
Code that may be relevant
git-cliff/git-cliff-core/src/commit.rs
Lines 115 to 120 in 848d8a5
Thank you.
Describe the bug
This might just be my misunderstanding of how to format conventional commits, but I am running into an issue where git-cliff
is not picking up the full message of multiline commits. I would expect it to be able to include the full commit message in the changelog even if it has newlines present.
To Reproduce
Steps to reproduce the behavior:
Create a multiline commit message.
The full message appears in the gitlog.
However when I create the changelog, only the message up to the newline is present.
Expected behavior
I would expect it to be able to include the full commit message in the changelog even if it has newlines present.
System (please complete the following information):
Describe the bug
I want my commits to be sorted by the newest time. However, it does not work using sort_commits = "newest"
but it works using --sort newest
To Reproduce
Steps to reproduce the behavior:
git clone https://github.com/orhun/git-cliff
cd git-cliff
git-cliff --config config/cliff.toml --tag 0.1.0-beta.3
sort_commits = "oldest"
to sort_commits = "newest"
in /git-cliff/config/cliff.toml
git-cliff --config config/cliff.toml --tag 0.1.0-beta.3
The order is same. no chages
sort_commits = "newest"
line the config. git-cliff --config config/cliff.toml --tag 0.1.0-beta.3 --sort newest
and git-cliff --config config/cliff.toml --tag 0.1.0-beta.3 --sort oldest
. Now it works.Expected behavior
sort_commits = "newest"
should output the same exact thing as --sort newest
Screenshots/Logs
Attached.
System (please complete the following information):
❯ git-cliff --version
git-cliff 0.4.2, version: https://github.com/orhun/git-cliff/commit/02a6187a58583f27e4604d7ea518b52b4bc7a833
OS: Debian GNU/Linux 11 (bullseye)
Kernel: Linux 5.10.0-9-amd64 x86_64
Additional context
Thanks for git-cliff.
Hello, we're evaluating using git-cliff for our monorepo, in order to automate the generation of the CHANGELOG. The tool looks really powerful!
We have a couple of questions:
Describe the bug
git cliff --unreleased --tag 14.0.0 --prepend ./CHANGELOG.md
If a repo is needed:
https://github.com/discordjs/discord.js
Running:
cd packages/discord.js
git cliff --unreleased --tag 14.0.0 --prepend ./CHANGELOG.md -c ../../cliff.toml -r ../../
Will reproduce it, otherwise similar steps will most likely work too on any repo.
To Reproduce
[changelog]
header = """
# Changelog
All notable changes to this project will be documented in this file.\n
"""
body = """
{% if version %}\
# [{{ version | trim_start_matches(pat="v") }}]\
{% if previous %}\
{% if previous.version %}\
(https://github.com/discordjs/discord.js/compare/{{ previous.version }}...{{ version }})\
{% else %}
(https://github.com/discordjs/discord.js/tree/{{ version }})\
{% endif %}\
{% endif %} \
- ({{ timestamp | date(format="%Y-%m-%d") }})
{% else %}\
# [unreleased]
{% endif %}\
{% for group, commits in commits | group_by(attribute="group") %}
## {{ group | upper_first }}
{% for commit in commits %}
- {% if commit.breaking %}\
[**breaking**] \
{% endif %}\
{% if commit.scope %}\
**{{commit.scope}}:** \
{% endif %}\
{{ commit.message | upper_first }} ([{{ commit.id | truncate(length=7, end="") }}](https://github.com/discordjs/discord.js/commit/{{ commit.id }}))\
{% endfor %}
{% endfor %}\n
"""
trim = true
footer = ""
[git]
conventional_commits = true
filter_unconventional = true
commit_parsers = [
{ message = "^feat", group = "Features"},
{ message = "^fix", group = "Bug Fixes"},
{ message = "^docs", group = "Documentation"},
{ message = "^perf", group = "Performance"},
{ message = "^refactor", group = "Refactor"},
{ message = "^typings", group = "Typings"},
{ message = "^types", group = "Typings"},
{ message = ".*deprecated", body = ".*deprecated", group = "Deprecation"},
{ message = "^revert", skip = true},
{ message = "^style", group = "Styling"},
{ message = "^test", group = "Testing"},
{ message = "^chore", skip = true},
{ message = "^ci", skip = true},
{ message = "^build", skip = true},
{ body = ".*security", group = "Security"},
]
filter_commits = true
tag_pattern = "[0-9]*"
skip_tags = "v[0-9]*|11|12"
ignore_tags = ""
topo_order = false
sort_commits = "newest"
Expected behavior
Expect previous
to be populated to based on the latest actual tag so the desired compare link can be generated with the config above.
Screenshots/Logs
Generated by creating a git tag manually and then running: git cliff --latest --prepend ./CHANGELOG.md
Generated by not creating a git tag and running git cliff --unreleased --tag 14.0.0 --prepend ./CHANGELOG.md
System (please complete the following information):
Is your feature request related to a problem? Please describe.
Hi @orhun
This is not directly related to git-cliff, as you know I am refactoring the cocogitto changelog logic to use git-cliff internals.
Now I am facing the following dilemma :
cocogitto uses conventional_commit_parser, git-cliff uses git-conventional which does exactly the same.
In order to integrate git-cliff I need either to use git-conventional and drop conventional_commit_parser or do the opposite in
git-cliff.
Describe the solution you'd like
I am biased toward the library I wrote but I think it has a few cons :
If you are ok with this I can make a draft PR in git-cliff.
Describe alternatives you've considered
If you have some good reason to stick with git conventional I'll refactor on cocogitto's side to get this done. Let me know.
Having a separate config file just for a few values (hint hint #45) seems like overkill.
It seems like it would be pretty easy to check for a custom section in Cargo.toml for Rust projects. As a bonus with some json maybe also look at package.json, pyproject.toml, etc. Most of these formats allow project meta data in custom keys.
Is your feature request related to a problem? Please describe.
no
Describe the solution you'd like
use git cliff in git hook to check that a given commit message or a message given as parameter match conventional syntax
Describe alternatives you've considered
using a script, but git cliff has everything internally to do the job and can follow the project specific syntax from its toml config file
Additional context
The current config file system seems to require all required keys to be present. I am more comfortable with (and most programs support) only setting the values that I want to be different than the defaults. It would be nice if this was possible.
For context:
I'm using in my changelog usually links that point to GitHubs version compare pages like this:
## [Unreleased]
[Unreleased]: https://github.com/steganogram/stegano-rs/compare/v0.5.0...HEAD
## [0.4.10] - 2021-11-15
[0.4.10]: https://github.com/steganogram/stegano-rs/compare/v0.4.10...v0.4.9
so there are links that points to the GitHub code compare, for the actual version (v0.4.10
) with the "previous" (v0.4.9
) semver version that was released, and the last released version (v0.5.0
) with the HEAD
In order to make this same changelog available by cliff I've tried the cliff.toml
as below:
# template for the changelog body
# https://tera.netlify.app/docs/#introduction
body = """
{% if version %}\
## [{{ version | trim_start_matches(pat="v") }}] {{ timestamp | date(format="%Y-%m-%d") }}
[{{ version | trim_start_matches(pat="v") }}]: https://github.com/sassman/putzen-rs/compare/{{ version }}...{{ previous_version }}
{% else %}\
## [unreleased]
[Unreleased]: https://github.com/sassman/putzen-rs/compare/{{ latest_version }}...HEAD
{% endif %}\
I guess this variables could be very tricky to provide, but maybe when assuming semver version tags it might be possible to have them all parsed and prepared for the tera rendering.
Alternatively it might be a filter available that goes to the previous version of a given version number like this:
[{{ version | trim_start_matches(pat="v") }}]: https://github.com/sassman/putzen-rs/compare/{{ version }}...{{ version | previous_release }}
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.