GitHub Release Impact & Issue Regression Intelligence

Analyze public GitHub issue reporting before and after a software release. This Actor resolves a release boundary, excludes pull requests returned by GitHub's Issues API, samples both periods deterministically, and reports issue-volume changes, bug/regression signals, emerging themes, worsening or decreasing themes, representative evidence, coverage, and confidence.

This is an impact-intelligence report, not a raw GitHub Issues scraper. Regression signals describe temporal changes observed after a release; they do not prove that the release caused an individual issue.

Input

The default input compares the latest eligible release of vitejs/vite over seven-day windows. comparisonMode can be latest_eligible_release, release_tag, custom_date, or recent_vs_previous. release_tag requires one repository and a tag; a supported GitHub release URL can supply the tag. custom_date requires an ISO comparisonDate. maxIssuesPerPeriod controls the deterministic analysis sample, while bounded pagination collects enough history to cover both windows.

An optional githubToken increases public GitHub API rate limits. It is never logged or included in output. No token, browser, proxy, LLM, or external search service is required for the Store default.

Output

One Dataset item is produced per requested repository. Successful and partial items contain the resolved boundary, before/after period metrics, impact direction and level, theme deltas, feature-request counts, bounded issue evidence, coverage, warnings, request statistics, and a deterministic summary. A repository failure becomes a failed item so other repositories can finish.

Output fields

Field	Meaning
status	Repository result status.
repository.fullName	Canonical owner/repository name.
boundary.release.tag	Exact selected release tag, when applicable.
boundary.timestamp	Comparison boundary timestamp.
impact.direction	Observed regression-signal direction.
impact.level	Low, medium, high, or unknown impact level.
impact.issueVolume.before	Issues analyzed before the boundary.
impact.issueVolume.after	Issues analyzed after the boundary.
impact.issueVolume.absoluteDelta	Difference in analyzed issue counts.
impact.bugSignalRateDelta	Change in bug-related signal share.
impact.regressionSignalRateDelta	Change in regression-related signal share.
coverage.before.coverageStatus	BEFORE evidence coverage.
coverage.after.coverageStatus	AFTER evidence coverage.
impact.confidence.level	Evidence-quality confidence level.
summary	Deterministic non-causal summary.
warnings	Structured collection and coverage warnings.
error.code	Failure code for failed repository items.
fetchedAt	Report generation timestamp.

Coverage is first-class: full means the requested period was reached with enough analyzed issues and no known truncation; partial means usable evidence exists with an incomplete window or safety limitation; insufficient means the sample is too small for directional analysis. Confidence is an evidence-quality score, not a probability of causation.

API behavior and limitations

The Actor uses GitHub REST release and repository Issues endpoints with state=all, chronological creation sorting, bounded pages, and per_page=100. GitHub's Issues endpoint can return pull requests; every item with pull_request is excluded. Comments are not crawled by default. V1 does not analyze discussions, pull requests, commits, diffs, source code, private repositories, security vulnerabilities, alerts, or webhooks. Rate limits produce structured warnings or partial output where useful.

Scheduling and pricing

Schedule periodic runs to compare rolling windows or monitor releases. The intended Pay Per Event unit is one successful repository release report; pricing remains provisional until measured runtime and API economics are documented.

FAQ

Does this prove a release caused a bug? No. It identifies elevated or changed issue-reporting signals around a boundary.

Why can a recent release fall back to rolling mode? A release must be old enough to provide the requested after window. If no eligible release is available, the report states the fallback explicitly.

Why is coverage partial? The period may still be active, contain too few issues, hit bounded pagination, or encounter a GitHub rate limit.