Include the folder in the templating context

[CBenoit]

Is there an existing issue or pull request for this?

• I have searched the existing issues and pull requests

Feature description

I would like the current folder to be included into the templating context. This is mostly for filtering purposes.

Desired solution

Include the folder in the context.

Alternatives considered

None.

Additional context

In a workspace, I’m using scopes to specify the crate affected by a change. It may happen that I need to change code in other crates to accommodate this change, however for these crates it’s only an internal modification that is not visible in the public API. Since the commit is affecting these crates too, the generated changelog unfortunately reflects that too and I need to remove the unwanted entries manually.

[welcome]

Thanks for opening your first issue at git-cliff! Be sure to follow the issue template! ⛰️

[orhun]

Hello 👋🏼

There is a repository field in the context, wouldn't that work for your use case?

 "repository": "/path/to/repository",

[CBenoit]

Hello!

I think repository will give me a path to the root folder, not the folder of the project inside the repository. Let me check if my understanding is erroneous.

[CBenoit]

Sorry, I wasn’t able to get the repository field populated, it’s always an empty string 🤔

body = """
[repository: {{ repository }}]
"""

↓

[repository: ]

[orhun]

Hmm that's weird. I am unable to reproduce that locally. Do you also not see in the JSON context? (run it with -x flag)

I think repository will give me a path to the root folder, not the folder of the project inside the repository. Let me check if my understanding is erroneous.

But yes, you probably need the current folder instead of the root of the repository so that wouldn't work.

I'm not sure if I understood your reasoning for that fully - do you mind giving a bit more explanation about your setup and desired changelog format so that maybe we can find a way to handle that without additional implementation?

[CBenoit]

In this case, I’m using git-cliff via release-plz, maybe it’s related to how they are using the git-cliff-core crate?

I tried to find a combination of flags to produce the same result as release-plz, something like this:

git-cliff --output crates/some-crate/CHANGELOG.md  some-crate-v0.1.0..HEAD --include-path crates/some-crate

But I wasn’t able to get the same output. For some reason, the commits affecting the crates/some-crate folder are ignored and I get an empty changelog (or an empty context when using -x); while git-cliff via release-plz is properly finding the commits… Not sure what I’m doing wrong, but since it’s not related to the current issue, let’s forget about this for now.

Let me give you more context on what I’m trying to achieve. I configured release-plz to run in our CI at IronRDP, and it now opens this kind of PRs.

I experimented locally with various commits and a pain point I noticed is that we are getting changelog entries that are not always relevant because of the monorepo nature associated to the not-rocket-science rule of keeping each commit as a compilable state:

• Modify crates A by adding a new item (minor bump) or modifying an item (major bump).
• Crate B is depending on crate A and uses it internally without exposing anything from it.
• To keep the project compiling, I need to update crate B in the same commit.

Ideally, we should bump the patch number of crate B and the changelog should simply mention that crate A dependency was updated.
Currently, the new version of crate B is inferred from the commit which modified crate A, and the minor or major number is bumped. The changelog also includes a note about the change in crate A, which is not really relevant to a consumer of crate B.

I’m still investigating ways of improving all of this and thought that some filtering at the template level could help automate some of this in a better way. The scope of our commit is the name of the crate that is modified (e.g.: feat(a)).
At this point, I don’t think that using convential commits is a good solution to this specific problem in monorepos (or we need to accept commits which are temporary breaking the compilation of some crates), but it’s still better than nothing even if I need to manually update the release PR from time to time to adjust things.