analytics-repo-pruning

To identify archived and stale GitHub repositories, you can run a script that parses a repos.json file, authenticates to the host API, and checks the pushed_at activity signal to bucket each repo by status. This produces a structured report without modifying your input data.

The default inactivity threshold for flagging a stale repository is 730 days without meaningful code activity. Repositories exceeding this duration since their last pushed_at signal are bucketed as stale for analytics pruning.

Yes, you need authenticated API access to check GitLab or GitHub repository activity. The tool relies on your existing environment credentials to fetch activity signals like pushed_at from the hosting provider to accurately verify repository status.

You can audit repository status without modifying the original repos.json file by running a read-only pruning script. It classifies entries into archived, stale, could not verify, or active buckets and outputs a separate structured report for safe cleanup.

If a repository cannot be verified during the pruning audit, it is sorted into a dedicated 'could not verify' bucket. This happens when API access fails or the host cannot provide a valid pushed_at activity signal for the entry.

The input repos.json format requires a top-level repos array containing objects with both git and name fields. The script determines the hosting provider from the git field to fetch the last activity signals needed for classification.