[lockfile-stats] Lockfile Statistics Analysis — 2026-08-20

[github-actions[bot]]

Lockfile Statistics — 2026-08-20

Analysis of all .github/workflows/*.lock.yml compiled workflow lockfiles in github/gh-aw, generated via a single-script compact JSON pass (no per-file cat/grep).

Executive summary

Metric	Value
Lockfiles analyzed	286 (0 skipped)
Total size	40,508,914 bytes (~38.6 MiB)
Avg / min / max size	~141.6 KB / 84.6 KB / 224.6 KB
workflow_dispatch present	279 / 286 (97.6%)
schedule present	192 / 286 (67.1%)

File size distribution

• Smallest: example-permissions-warning.lock.yml (84.6 KB), codex-github-remote-mcp-test.lock.yml (84.9 KB), notion-issue-summary.lock.yml (85.4 KB)
• Largest: smoke-copilot.lock.yml (224.6 KB), smoke-copilot-aoai-entra.lock.yml (224.5 KB), smoke-copilot-aoai-apikey.lock.yml (221.9 KB)
• 6 of the top-10 largest lockfiles are smoke-* integration/test workflows — these appear to embed more setup/config boilerplate than typical workflows.

Trigger analysis

Trigger	Count	%
workflow_dispatch	279	97.6%
schedule	192	67.1%
pull_request	41	14.3%
issues	5	1.7%
issue_comment	3	1.0%
workflow_call	2	0.7%
deployment_status / workflow_run / discussion / discussion_comment / push / pull_request_review_comment	1 each	0.3%

Top trigger combinations: schedule + workflow_dispatch (189), workflow_dispatch only (48), pull_request + workflow_dispatch (36).

Cron schedules are almost entirely unique per-minute/hour offsets (only a handful repeat 2–3×, e.g. 7 5 * * * ×3), indicating deliberate staggering to avoid a scheduling thundering herd. ~9 workflows use interval-style crons (*/6, */4, */2, */7, */12).

Safe outputs analysis

Raw substring match counts across compiled files (includes prompt/schema text, so these overcount relative to per-workflow adoption — see Methodology):

Safe output	Mentions
create-pull-request	2,040
create-discussion	1,963
create-issue	1,267
add-comment	655
create-pull-request-review-comment	85
update-issue	55
noop / missing_tool / missing_data (control outputs)	3,337 / 2,820 / 1,407

Discussion category breakdown was not extractable via the regex fallback (see Methodology).

Structural characteristics

Metric	Max	Min	Avg
Steps per workflow	200	82	139.2
Script (run:) blocks per workflow	125	50	89.7

Job counts could not be reliably extracted by the fallback parser (indentation-dependent regex missed nested runs-on: markers) — omitted rather than reported as zero.

Permission patterns

Not available this run — the regex fallback did not reliably locate permissions: blocks without a real YAML parser. Flagged as a gap rather than reported as "no write permissions."

Tool & MCP patterns

Engine distribution (matched 247 / 286 lockfiles):

Engine	Count
copilot	172 (60.1%)
claude	60 (21.0%)
codex	15 (5.2%)
unmatched	39 (13.6%)

MCP server mentions: safeoutputs (286 — present in every lockfile, expected), github (117), mcpscripts (12), plus a v1-labeled match (1,237) that is very likely a false positive from JSON schema/version fields rather than a real server name — not reported as a finding.

Interesting findings

1. 97.6% of lockfiles support manual dispatch — near-universal, suggesting workflow_dispatch is a house convention for debuggability even on scheduled jobs.
2. Two-thirds of workflows (66%) are schedule + workflow_dispatch — the dominant pattern is a recurring job that can also be triggered ad hoc.
3. Cron times are staggered, not clustered — almost no two workflows share a fire time, consistent with intentional load spreading.
4. Copilot is the leading engine (60% of matched lockfiles) vs. Claude (21%) and Codex (5%), with 14% unmatched by the fallback pattern.
5. smoke-* test workflows are the largest lockfiles — 6 of the top 10 by size, likely due to broader tool/config surface for integration testing.

Historical trends

No prior summary found in cache memory (/tmp/gh-aw/cache-memory/history/) — this is the first recorded baseline (2026-08-20). Future runs can diff against this snapshot.

Recommendations

• Re-run with a working PyYAML install (this sandbox had no PyPI egress) to fill the gaps in job counts, permissions, discussion categories, and MCP tool names — the regex fallback is a lower bound, not a null result.
• If safe-output counts are needed per-workflow (not raw substring counts), a proper YAML-parse pass should count schema occurrences under each workflow's own jobs.*.safe-outputs config rather than scanning raw text.
• Consider whether the ~13.6% of lockfiles with an undetected engine reflects an actual gap in engine tagging or just a parser miss.

Methodology note: single-script compact JSON analysis. PyYAML was unavailable in this environment (no network egress to install it), so yaml_available=false and the analyzer used a regex/text fallback instead of a real YAML parse. This fallback reliably populated triggers, cron, safe-output/engine substring counts, and step/script counts, but could not reliably populate job counts, permissions, discussion categories, or MCP tool names — those are reported as unavailable/omitted rather than as zero, per the parser-reliability requirement.

Generated by 📊 Lockfile Statistics Analysis Agent · agent · 40.5 AIC · ⌖ 12.9 AIC · ⊞ 6.2K · ◷

• expires on Aug 21, 2026, 12:30 PM UTC-08:00