feat(cli): generate changelog from JSON context

[janbuchar]

Description

This implements generating a changelog from a pre-generated JSON context, which allows for more extensibility.

Motivation and Context

• closes Support generating changelog from a JSON context #657

How Has This Been Tested?

As of now, only manual tests have been performed. I'm not sure what the best strategy for unit-testing this would be.

Types of Changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (no code change)
• Refactor (refactoring production code)
• Other

Checklist:

• My code follows the code style of this project.
• I have updated the documentation accordingly.
• I have formatted the code with rustfmt.
• I checked the lints with clippy.
• I have added tests to cover my changes.
• All new and existing tests passed.

[welcome]

Thanks for opening this pull request! Please check out our contributing guidelines! ⛰️

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 20.00000% with 32 lines in your changes missing coverage. Please review.

Project coverage is 39.40%. Comparing base (b8045e9) to head (135938f).
Report is 186 commits behind head on main.

Files with missing lines	Patch %	Lines
git-cliff/src/lib.rs	0.00%	30 Missing ⚠️
git-cliff-core/src/changelog.rs	77.78%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #784      +/-   ##
==========================================
- Coverage   39.61%   39.40%   -0.20%     
==========================================
  Files          20       20              
  Lines        1606     1632      +26     
==========================================
+ Hits          636      643       +7     
- Misses        970      989      +19     

Flag	Coverage Δ
unit-tests	39.40% <20.00%> (-0.20%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[janbuchar]

This would be more useful if we added an optional free-form dictionary (e.g., additional_data) to both Release and Commit. In the current state, we may only change the existing context fields.

[orhun]

Damn, this is nice! Thanks for going ahead and implementing it 🔥

This would be more useful if we added an optional free-form dictionary (e.g., additional_data) to both Release and Commit. In the current state, we may only change the existing context fields.

I definitely agree, would love to have that. We can use serde_json::Value for that I reckon.

A couple of things:

• We should update the documentation about this. We can create a new page under /docs/usage. (I'm okay with adding it if you are not interested :))
• Can you add a fixture test to verify this behavior?

[janbuchar]

Damn, this is nice! Thanks for going ahead and implementing it 🔥

This would be more useful if we added an optional free-form dictionary (e.g., additional_data) to both Release and Commit. In the current state, we may only change the existing context fields.

I definitely agree, would love to have that. We can use serde_json::Value for that I reckon.

Great! Is extra an acceptable name? The originally proposed additional_data is also an OK option, but a bit long IMO.

• We should update the documentation about this. We can create a new page under /docs/usage. (I'm okay with adding it if you are not interested :))

If you could just push a file with some kind of an outline here, I'll be glad to fill it in.

• Can you add a fixture test to verify this behavior?

Absolutely, once we've settled on the extra attribute name.

[orhun]

Yes, I think extra (or extra_data or custom_data) is a good name!

[janbuchar]

@orhun I added the extra attribute and a fixture test. However, it seems like there is a bug - the commit.extra field gets lost somewhere on its way into the template. I found that it is still present in changelog.rs#542 (line 530 in current main, I did a dbg!(&release) there), but it is not present inside the Template.render method. How can that happen?

[orhun]

Ah, there is a custom Serialize implementation for Commit where you should add the new field :)

git-cliff/git-cliff-core/src/commit.rs

Line 397 in a71649b

impl Serialize for Commit<'_> {

[janbuchar]

@orhun I added a simple docs page and everything except Docker automated builds passed - those are still running.

[orhun]

Hot stuff 🔥

I pushed some commits to improve this even further:

• now supports GIT_CLIFF_CONTEXT environment variable
• remote data is made available via calling add_remote_data on context
• support stdin out of the box via checking is_terminal() (e.g. cat context.json | git-cliff)
• updated docs

I think this opens so many doors as an extension point, so thanks a lot again! <3

[orhun]

Oops, is_terminal() check seems to have broken the fixture tests, I will look into it later.

ref: 135938f

[janbuchar]

Thanks for the review and for the improvements, I can't wait to use it!

[orhun]

Will cook up a release pretty soon 🤞🏼

[welcome]

Congrats on merging your first pull request! ⛰️