Repository navigation
Tracking: adopt commit/PR streaming end-to-end in downstream consumers #1337
Description
Activity
One significant downstream consumer is @release-plz. We could potentially look at what they are doing and start from there.
Reacted by Shingo OKAWAOne significant downstream consumer is @release-plz. We could potentially look at what they are doing and start from there.
Thanks for the pointer. That makes sense.
In my case, the downstream usage I had in mind is currently contained within
git-cliff-coreitself, specifically around these areas:git-cliff/git-cliff-core/src/changelog.rs
Lines 262 to 275 in 0b6af12
let data = tokio::runtime::Builder::new_multi_thread() .enable_all() .build()? .block_on(async { let (commits, pull_requests) = tokio::try_join!( github_client.get_commits(ref_name), github_client.get_pull_requests(ref_name), )?; log::debug!("Number of GitHub commits: {}", commits.len()); log::debug!("Number of GitHub pull requests: {}", pull_requests.len()); Ok((commits, pull_requests)) }); log::info!("{}", github::FINISHED_FETCHING_MSG); data git-cliff/git-cliff-core/src/remote/mod.rs
Lines 310 to 314 in 0b6af12
pub fn $fn( &mut self, mut commits: Vec<Box<dyn RemoteCommit>>, pull_requests: Vec<Box<dyn RemotePullRequest>>, ) -> Result<()> {
That said, from my personal perspective, I think there's also an option to gradually move toward a stream-based API more broadly, for example, keeping the existing non-stream-based APIs for now but marking them as
#[deprecated], and transitioning incrementally.This would obviously need some discussion and agreement, but I wanted to put it on the table as a possible direction.
Reacted by Orhun Parmaksız
Is there an existing issue or pull request for this?
Feature description
The remote layer was recently refactored to expose commits and pull requests as streams (PR #1272). While this clears the way for smarter request strategies and performance improvements, the downstream code
still eagerly collects these streams into
Vecs and processes them in a non-streaming fashion.As a result, the current implementation does not yet benefit from:
In other words, the streaming abstraction is not yet reflected end-to-end.
Desired solution
Adopt streaming semantics throughout downstream consumers so that commit and pull request data can be processed incrementally instead of being fully materialized upfront.
This issue is intended as a tracking issue, and the work can be implemented incrementally across multiple follow-up PRs.
Alternatives considered
These alternatives do not fully realize the benefits enabled by the stream-based remote refactor.
Additional context
Related PR: #1272