feat: support context json schema dump

[greenhat616]

Description

Close #1294. Add JSON Schema dump feature.

Current blocked by crate-ci/git-conventional#88.

Motivation and Context

Add a gloabl opt --dump-context-schema to dump current version Context JSON Schema.

How Has This Been Tested?

Screenshots / Logs (if applicable)

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

❌ Patch coverage is 47.91667% with 25 lines in your changes missing coverage. Please review.
✅ Project coverage is 43.03%. Comparing base (85cc05d) to head (572e139).

Files with missing lines	Patch %	Lines
git-cliff-core/src/changelog.rs	60.00%	12 Missing ⚠️
git-cliff/src/lib.rs	0.00%	9 Missing ⚠️
git-cliff/src/main.rs	0.00%	3 Missing ⚠️
git-cliff-core/src/remote/mod.rs	75.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1296      +/-   ##
==========================================
- Coverage   43.46%   43.03%   -0.43%     
==========================================
  Files          22       22              
  Lines        1972     1992      +20     
==========================================
  Hits          857      857              
- Misses       1115     1135      +20     

Flag	Coverage Δ
unit-tests	43.03% <47.92%> (-0.43%)	⬇️

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.

[ognis1205]

First, please run the formatter with:

cargo +nightly fmt --all -- --verbose

and then run clippy with:

cargo clippy --tests --verbose -- -D warnings

to ensure the code passes both checks.

While using schemars to generate JSON Schemas in a code-first manner from the git-cliff-core and git-conventional models isn't necessarily a bad idea, both crates already expose their internal models publicly. Given that, adding schema-generation logic directly into the CLI might slightly drift away from the core purpose of git-cliff, which is primarily a changelog generator.

If you still prefer to support schema generation, you might consider isolating that functionality. For instance, by using remote deriving, you could maintain a small separate project that depends on git-cliff-core and git-conventional, and generate schemas there instead.

This would keep the CLI focused on its main responsibility while still enabling schema generation for external tooling.

[greenhat616]

I have done the fmt and clippy check.

Regarding the Schema → SDK issue: I agree this workflow is not ideal in most cases. While Cliff does not define a stable Schema version, every change to Context can break existing interfaces—and when using Python or TS there is no type checking at runtime. Therefore, if we use a Schema, we must pin the current Cliff version.

Regarding Schema generation, after careful consideration, I approved for defining a separate remote definition for git-conventional. However, the Release type inside git-cliff-core is quite complex; defining it in a third-party library would require significant effort to adapt after each release.

This PR is just a draft idea for now. Maybe a better a approach: We could gate this with a feature flag and, via some process (scripts or an xtask, etc.), generate a Schema when Cliff publishes a release and upload it to the Releases artifacts. Would that be more appropriate?

[ognis1205]

cc: @orhun

Thanks for clarifying. I understand this PR is still a draft.
However, it seems that some tests are failing. Have you run the tests locally to confirm?

Also, I’m a bit hesitant about this feature itself, as well as adding a related option to the CLI. We should consider whether this functionality is truly needed for most users. Even if it is, it might be cleaner, from a separation-of-concerns perspective, to add a separate binary under git-cliff-core rather than integrating it into the main CLI.

I agree this workflow is not ideal in most cases.

As you also noted, the current implementation direction seems problematic to me as well.

defining it in a third-party library would require significant effort to adapt after each release.
generate a Schema when Cliff publishes a release and upload it to the Releases artifacts.

In other words, what's being proposed here effectively shifts the maintenance burden to the maintainers, before we've even established a clear need for the feature. I think we should have a more thorough discussion about the necessity and maintenance cost of this functionality before proceeding further.

Personally, I would still recommend creating a separate repository dedicated to schema generation, which could depend on both git-cliff-core and git-conventional.

[orhun]

Hey, sorry for the delay on this. I'll be having a look soon hopefully