Repository navigation
[lockfile-stats] Lockfile Statistics Report — 2026-10-15 #69101
Closed
Replies: 1 comment
|
This discussion has been marked as outdated by Lockfile Statistics Analysis Agent. A newer discussion is available at Discussion #69480. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Executive summary
Analyzed 344 compiled lockfiles (
.github/workflows/*.lock.yml) on 2026-10-15, totaling 53.5 MB (56,086,698 bytes). 0 files skipped as malformed.workflow_dispatchcreate_discussionFile size distribution
Trigger analysis
Top trigger combinations:
schedule+workflow_dispatch(214, 62%),workflow_dispatchonly (71, 21%),pull_request+schedule+workflow_dispatch(33, 10%),pull_request+workflow_dispatch(9),pull_requestonly (3).Most common cron:
0 0 */2 * *(every 2 days at midnight UTC) — used by 60 workflows, 24% of all 251 scheduled workflows. No other cron pattern is used by more than 3 workflows.Safe outputs analysis
Baseline control-flow outputs (
noop,missing_data,missing_tool,report_incomplete,create_report_incomplete_issue) are each wired into 337 of 344 workflows (98%), confirming near-universal adoption of the standard safe-outputs scaffolding.Top substantive safe-output types:
† One additional workflow has
create_discussionconfigured but its category couldn't be resolved (see below), for 93 totalcreate_discussionworkflows.Discussion categories (92 of 93 resolved — 99% detection rate):
pr-sous-chef.lock.ymlis the one workflow wherecreate_discussionis present but no category (explicit ordefault) could be resolved from config or fallback parsing — a 1.1% gap, within tolerance but worth a manual check.safe_outputs_config_missing: 1 lockfile had no parsableGH_AW_SAFE_OUTPUTS_CONFIG/HANDLER_CONFIGenv value at all (same workflow as above).Full safe-output type counts (click to expand)
create_issue 183 · create_discussion 92 · add_comment 74 · create_pull_request 65 · push_repo_memory 33 · add_labels 32 · upload_asset 26 · mentions 24 · create_pull_request_review_comment 16 · submit_pull_request_review 16 · upload_artifact 15 · create_check_run 14 · update_issue 10 · push_to_pull_request_branch 10 · max_bot_mentions 9 · dispatch_workflow 9 · ledger_append 7 · close_issue 7 · remove_labels 7 · ledger_request_compaction 6 · comment_memory 6 · assign_to_agent 5 · link_sub_issue 4 · update_pull_request 4 · close_pull_request 4 · send-slack-message 4 · create_code_scanning_alert 3 · close_discussion 3 · reply_to_pull_request_review_comment 3 · set_issue_type 3 · and 18 more types at 1-2 workflows each (hide_comment, assign_to_user, create_agent_session, upload_code_coverage, jira_*, linear_create_issue, update_project, etc.)
Structural characteristics
run:/with.script)Permission patterns (agent job, not the always-empty top-level block)
Agent-job scopes are overwhelmingly read-only; only
copilot-requestsandid-tokenever appear aswriteat the agent-job level:permissions_unknown: 0 — every lockfile's agent-job permissions resolved cleanly.Union across all jobs (any job granting write) tells a different story — write access is pushed into dedicated publisher jobs:
issueswrite appears in 342/344 workflows (99%),contentsin 229 (67%),copilot-requestsin 166 (48%),pull-requestsin 151 (44%),discussionsin 96 (28%). 342 of 344 workflows (99.4%) grant write somewhere in their job graph.Engine distribution
(from
gh-aw-metadataagent_id, 0 unresolved)Tool & MCP patterns
MCP server usage (from
gh-aw-manifest; 7 lockfiles fell back to legacy tool-comment scraping):Interesting findings
copilot-requests/id-tokenever write there), while 99.4% of workflows grant write somewhere else in the job graph — writes are consistently delegated to dedicated safe-output publisher jobs, not the reasoning agent.create_discussionworkflows (79/92) target theauditscategory — this very report included — versus a long tail of 6 other categories.0 0 */2 * *, a potential simultaneous-runner-start spike every other midnight UTC.pr-sous-chef.lock.ymlhascreate_discussionconfigured but no detectable category via config or fallback regex — the sole gap in an otherwise 99%-detected dataset.Historical trends (vs. 2026-10-14)
Lockfile count, trigger counts, safe-output type counts, discussion categories, engine distribution, and MCP usage are all unchanged day-over-day — only compiled sizes and job/step counts grew slightly, consistent with routine recompilation rather than substantive workflow changes:
contentswrite (union)Recommendations
pr-sous-chef.lock.yml'screate_discussionconfiguration to close the one unresolved discussion-category case.0 0 */2 * *need staggering to avoid simultaneous runner starts.Methodology note
single-script compact JSON analysis
References:
All reactions