Skip to content

Conversation

@ognis1205
Copy link
Contributor

@ognis1205 ognis1205 commented Jan 12, 2026

Description

Enable the tokio-runtime feature for the cacache dependency in git-cliff-core.

Motivation and Context

In the workspace root, cacache is already resolved with an async runtime enabled due to transitive dependencies from the CLI:

$ cargo tree -f "{p} {f}" | grep cacache
├── cacache v13.1.0 futures,libc,memmap2,mmap,tokio,tokio-runtime,tokio-stream
├── http-cache-reqwest v0.15.0 default,manager-cacache
│   ├── http-cache v0.20.0 bincode,cacache,cacache-tokio,manager-cacache
│   │   ├── cacache v13.1.0 futures,libc,memmap2,mmap,tokio,tokio-runtime,tokio-stream (*)

However, when building git-cliff-core in isolation, cacache is currently resolved without any async runtime enabled:

$ cargo tree -f "{p} {f}" | grep cacache
├── cacache v13.0.0 libc,memmap2,mmap

As a result, cargo build succeeds at the workspace level, but cargo msrv -p git-cliff-core check fails due to missing runtime-dependent types in cacache.

Additional context

How Has This Been Tested?

  • cargo build for git-cliff-core
  • cargo build for the workspace
  • cargo msrv to verify the configuration builds correctly under MSRV constraints

Screenshots / Logs (if applicable)

N/A

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.

@ognis1205 ognis1205 requested a review from orhun as a code owner January 12, 2026 02:59
@codecov-commenter
Copy link

codecov-commenter commented Jan 12, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 43.43%. Comparing base (081ba68) to head (a6194f1).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #1341   +/-   ##
=======================================
  Coverage   43.43%   43.43%           
=======================================
  Files          23       23           
  Lines        2245     2245           
=======================================
  Hits          975      975           
  Misses       1270     1270           
Flag Coverage Δ
unit-tests 43.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.

Copy link
Owner

@orhun orhun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for investigating this!

Note on enabling `tokio-runtime` for `cacache`:
- `git-cliff-core` itself does not rely on or directly use the `tokio-runtime` feature.
- However, when building the CLI (`git-cliff`), this feature is already enabled transitively
  via `http-cache-reqwest` (`feature = "manager-cacache"`), so it is resolved at the workspace level.
- As a result, enabling `tokio-runtime` here does not change the effective feature set for the released
  binary and does not impact binary size.
- This avoids build failures caused by runtime-less configurations, as discussed in:
  zkat/cacache-rs#92

Signed-off-by: Shingo OKAWA <[email protected]>
@ognis1205 ognis1205 force-pushed the fix/cacache-feature-resolution branch from d858e2f to a6194f1 Compare January 12, 2026 13:40
@ognis1205
Copy link
Contributor Author

thanks for investigating this!

Ideally, this should be addressed upstream in cacache, but I hope this can serve as a temporary workaround until that is resolved.

@ognis1205 ognis1205 requested a review from orhun January 12, 2026 13:42
@orhun orhun merged commit 619b0b1 into orhun:main Jan 12, 2026
96 checks passed
@ognis1205 ognis1205 deleted the fix/cacache-feature-resolution branch January 12, 2026 17:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants