Add cache and parallel run to Git Count Contributors

[attiasas]

feat(git): Add parallel scanning and caching to Git Count Contributors

depends on:

• Add ListRepositoriesByOwner API froggit-go#187

Summary

Introduces parallel repository scanning and a file-based cache layer to the git count-contributors command, significantly improving performance for large organizations with many repositories. Repositories are now scanned concurrently (configurable via --threads, default 10) and results are cached to disk (configurable via --cache-validity, default 3 days) to avoid redundant API calls on repeated runs.

Changes

• Parallel scanning: Refactored scanAndCollectCommitsInfo to scan repositories concurrently using gofrog/parallel.Runner. Each repo is scanned independently, and results are merged after all tasks complete.
• File-based cache: New cache.go module persists per-repo scan results as JSON files under ~/.jfrog/contributors-cache/<hash>/. Cache entries are keyed by a SHA256 hash of (scm-type, scm-api-url, owner, months) to avoid collisions. Writes are atomic (tmp + rename).
• New CLI flags:
  • --cache-validity — number of days a cached result remains valid (0 = skip cache, default 3).
  • --threads — number of parallel threads for scanning (default 10).
• Result types: Introduced repoScanResult and vcsServerScanResult structs to cleanly aggregate parallel results, along with mergeContributors, mergeDetailedContributors, and mergeDetailedRepos helper functions.
• Utility: Added GetContributorsCacheDir() in utils/paths.go.
• Tests: Added unit tests for cache round-trip, expiry, merge helpers, and parallel scanning via a new mockVcsClient test double.

Files changed

File	Status
cli/docs/flags.go	Modified — new CacheValidity, GitThreads flags
cli/gitcommands.go	Modified — parse new flags into params
commands/git/contributors/cache.go	Added — cache read/write/sanitize logic
commands/git/contributors/cache_test.go	Added — cache unit tests
commands/git/contributors/countcontributors.go	Modified — parallel scan, result structs, merge helpers
commands/git/contributors/countcontributors_test.go	Modified — merge and parallel scan tests
commands/git/contributors/mock_vcs_client_test.go	Added — full VcsClient mock for tests
utils/paths.go	Modified — GetContributorsCacheDir helper

Testing

• New unit tests cover cache write/read, cache expiry, zero-max-age bypass, missing cache files, all three merge helpers (empty src, non-overlapping, collision), and end-to-end parallel scanning with a mock VCS client.
• Existing tests continue to pass.

Notes

• Cache entries use the same months parameter in the key, so changing --months automatically invalidates stale cache.
• Setting --cache-validity 0 fully bypasses caching (no file I/O at all).

---

• The pull request is targeting the dev branch.
• The code has been validated to compile successfully by running go vet ./....
• The code has been formatted properly using go fmt ./....
• All static analysis checks passed.
• All tests have passed. If this feature is not already covered by the tests, new tests have been added.
• Updated the Contributing page / ReadMe page / CI Workflow files if needed.
• All changes are detailed at the description. if not already covered at JFrog Documentation, new documentation have been added.

[eranturgeman]

Suggested change

	if cacheDir != "" {
	if cacheDir != "" && cacheValidity > 0 {

Step 1 — buildRepoScanTasks (line 356):
if vcc.params.CacheValidity >= 0 { // 0 >= 0 → true
cacheDir = dir // cacheDir gets set to a real path
}
cacheValidity = 0 * 24 * time.Hour // = 0

Step 2 — scanRepo tries to read cache:
if cached := readRepoCache(cacheDir, repo, cacheValidity=0); ...
// Inside readRepoCache:
if maxAge <= 0 { return nil } // 0 <= 0 → returns nil immediately
So nothing is read from cache. ✓ correct so far.

Step 3 — scanRepo does a full scan, then tries to write cache:
if cacheDir != "" { // cacheDir was set in step 1 → true
writeRepoCache(...) // writes results to disk
}

So the user said "skip cache", got a full re-scan as expected, but their disk now has fresh cache files written to it that will never be read (since they always pass --cache-validity 0). On the next
run the same thing happens — full scan again, write again, never read.

[eranturgeman]

LGTM! see my comments

[github-actions]

---

🐸 JFrog Frogbot