New Feature·Pushed May 1, 2026·M
Commit analysis parallelized with configurable concurrency
GitPulse's commit analysis now runs concurrently — multiple commits are processed simultaneously rather than one after another, dramatically reducing runtime for repositories with many commits.
GitPulse can now analyze multiple commits at the same time instead of waiting for each one to finish. A new bounded-concurrency map utility processes up to N commits in parallel while preserving the original order of results.
The change introduces a configurable concurrency parameter (defaulting to 10) that controls how many commits are processed simultaneously. Each commit still runs through the complete pipeline: fetching file changes, looking up associated PR data via GraphQL, calling the LLM for summarization, assessing PR size, and writing the story output — just now with multiple pipelines running at once.
Output is now interleaved — a line appears when each commit finishes rather than waiting for all commits to complete sequentially. The final summary shows processed, total, and failed counts so users can quickly identify any commits that encountered errors.
The size assessment schema was consolidated to match gitsky's definitions, removing the duplication between the action and the backend service. Custom threshold configuration via JSON was removed in favor of the built-in defaults; more flexible customization remains a future phase.
In the action's GitHub workflow, a new [[code]]concurrency[[/code]] input lets operators tune the parallelism for their environment, trading off speed against API rate limits.
Technical description
This PR introduces parallel commit analysis to GitPulse's action, enabling concurrent processing that dramatically reduces analysis time for repositories with many commits.
**The core change: parallel processing via [[code ref=1]]pMap[[/code]]**
A new [[code]]pmap.ts[[/code]] provides a bounded-concurrency map function. Unlike a naive [[code]]Promise.all[[/code]] that would fire all tasks simultaneously, [[code ref=1]]pMap[[/code]] starts N workers that pull tasks from a shared queue. Results are written back to their original indices, preserving input order in the output array.
**[[code ref=2]]processCommit[[/code]] extracted for parallel execution**
The commit processing logic (file fetching, PR lookup, LLM summarization, size assessment, story writing) was extracted into a dedicated function. Each invocation returns a discriminated union: [[code]]{ ok: true, tag: string }[[/code]] or [[code]]{ ok: false, error: string }[[/code]]. The main loop uses [[code ref=1]]pMap[[/code]] to run multiple instances concurrently:
````mermaid
graph LR
A[Commits] --> B[pMap with concurrency N]
B --> C1[processCommit]
B --> C2[processCommit]
B --> C3[processCommit]
C1 --> D1[Story + stats]
C2 --> D2[Story + stats]
C3 --> D3[Story + stats]
D1 & D2 & D3 --> E[Final Summary]
````
**Configuration and wiring**
The workflow input [[code ref=4]]concurrency[[/code]] (default 10) flows through to the runtime config via [[code ref=5]]GITPULSE_CONCURRENCY[[/code]]. The config loader clamps the value between 1 and the number of commits:
````typescript
file=action/src/config.ts
concurrency: Math.max(1, Number(env.GITPULSE_CONCURRENCY ?? 10)),
````
**Schema consolidation**
The [[code ref=3]]SizeAssessmentSchema[[/code]] and [[code]]SizeAssessmentOutputSchema[[/code]] were moved from [[code]]size.ts[[/code]] to [[code]]schemas.ts[[/code]], mirroring the definitions from gitsky's pr-analysis service. This removes duplication and ensures type consistency across the monorepo.
The [[code]]size-thresholds[[/code]] workflow input was removed along with its JSON parsing logic. The built-in defaults now apply; custom formulas remain a future phase.
**Output changes**
Rather than one sequential block per commit, output now streams as each commit completes. The final line reports processed/total and failed counts:
````
[gitpulse] wrote 47/50 stories (3 failed)
````
**Files at a Glance**
- [[code]].github/workflows/analyze.yml[[/code]] — Added concurrency input, removed size-thresholds
- [[code]]action/src/config.ts[[/code]] — concurrency config (added), sizeThresholds removed
- [[code]]action/src/index.ts[[/code]] — Parallel loop via pMap, processCommit extracted, failed tracking added
- [[code]]action/src/pmap.ts[[/code]] — New utility: bounded-concurrency ordered map
- [[code]]action/src/schemas.ts[[/code]] — SizeAssessment schemas added
- [[code]]action/src/size.ts[[/code]] — Simplified: imports types from schemas, removed parseThresholds
- [[code]]action/src/render.ts[[/code]] — Type import updated to point to schemas.ts
- [[code]]action/src/types.ts[[/code]] — Consolidated import from schemas
Categories
- New Feature (50%) — New parallel commit analysis capability is the primary change, enabling concurrent processing of commits
- Performance (40%) — Parallel processing of up to N commits at a time significantly improves throughput for large repositories
- Refactoring (10%) — Schema consolidation (SizeAssessment moved to schemas.ts) is a secondary cleanup benefiting maintainability