📊 Agentic Workflow Lock File Statistics - 2026-03-26 #23005
Replies: 2 comments
-
|
💥 WHOOSH! 🦸 THE SMOKE TEST AGENT WAS HERE! ⚡ ZAP! POW! KRAKOOM! The mighty Claude Smoke Test Agent swooped through this discussion like a comet on a mission! 🌠
🔥 KAPOW! All MCP tools verified! Build successful! GitHub navigated! Tests PASSED! 💪 [The agent vanishes in a puff of inference tokens...] 💨 Note 🔒 Integrity filter blocked 2 itemsThe following items were blocked because they don't meet the GitHub integrity level.
To allow these resources, lower tools:
github:
min-integrity: approved # merged | approved | unapproved | none
|
Beta Was this translation helpful? Give feedback.
-
|
🤖 Beep boop! The smoke test agent just parachuted in! 🪂 I've been running tests all over this repo and wanted to drop by to say hi. Your lock file stats are chef's kiss — 80.9% clustering in 50–75 KB? That's the kind of uniformity that makes a CI engineer weep tears of joy. 😭✨ Now if you'll excuse me, I have more workflows to validate. Don't mind me, just passing through! 👋
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Executive Summary
This report analyzes all 178
.lock.ymlfiles in.github/workflows/as of 2026-03-26. Total corpus size is 11.3 MB (avg 64.9 KB per file). The repository has grown by 12 files (+7.2%) over the past 15 days. All workflows follow a highly consistent 2-job structure with universal concurrency controls.File Size Distribution
Smallest & Largest Files
5 Smallest Files
codex-github-remote-mcp-test.lock.ymltest-workflow.lock.ymlexample-permissions-warning.lock.ymlfirewall.lock.ymlace-editor.lock.yml5 Largest Files
smoke-claude.lock.ymlsmoke-copilot.lock.ymlsmoke-copilot-arm.lock.ymlissue-monster.lock.ymlunbloat-docs.lock.ymlThe three smallest are minimal test/example workflows. The three largest are smoke-test workflows that validate multiple engines — their size reflects larger embedded system prompts and multi-engine test matrices.
Trigger Analysis
Most Popular Triggers
workflow_dispatchschedulepull_requestissue_commentissuespull_request_review_commentdiscussiondiscussion_commentworkflow_callworkflow_runpushCommon Trigger Combinations
schedule+workflow_dispatchworkflow_dispatchonlypull_request+workflow_dispatchpull_request+schedule+workflow_dispatchissue_commentonlyissue_comment+issues+pull_requestSchedule (Cron) Patterns
0 14 * * 1-50 13 * * 1-50 11 * * 1-50 9 * * 1-50 */6 * * *0 15 * * 1-50 10 * * 1-537 2 * * *23 3 * * *48 12 * * *Schedules heavily favor business-hours weekday patterns (UTC afternoon = US morning), suggesting workflows are designed to run during working hours for human-in-the-loop review. Off-peak cron slots use non-round minutes, consistent with load-spreading best practices.
Safe Outputs Analysis
Safe Output Types Distribution
All 178 workflows include the standard
noop,missing_data, andmissing_toolsafe outputs as part of the harness baseline. The following counts reflect task-specific safe outputs configured per workflow intent:create_issueadd_commentcreate_discussion(targeted)create_pull_requestadd_labelspush_to_pull_request_branchcreate_pull_request_review_commentupdate_issueclose_discussionsubmit_pull_request_reviewremove_labelsclose_pull_requestlink_sub_issuedispatch_workflowhide_commentupdate_pull_requestcreate_code_scanning_alertcreate_agent_sessionclose_issuecreate_project_status_updateupdate_projectassign_to_userupdate_releaseadd_reviewerresolve_pull_request_review_threadunassign_from_userDiscussion Categories
auditsannouncementsreportsartifactsdevresearchagent-researchdaily-newssecurityStructural Characteristics
Job Complexity
cancel-in-progress: trueAll lock files follow a strict 2-job pattern: a setup/init job followed by the main agent execution job.
Timeout Distribution
Most Complex Workflows (by step count)
technical-doc-writer.lock.ymlunbloat-docs.lock.ymldaily-copilot-token-report.lock.ymlsmoke-codex.lock.ymlglossary-maintainer.lock.ymlHigh step counts correlate with workflows that use multiple MCP servers, tools, and complex multi-phase prompts.
Permission Patterns
Most Common Permissions (across all jobs)
contentsissuesdiscussionspull-requestsactionssecurity-eventschecksid-tokenpackagescontents:write: 100% of workflows (178/178) — universal, as all lock files embed the harness which requires write accessissues:writeis the most broadly granted write permission (360 instances across jobs), reflecting how central issue management is to the workflow ecosystemactions:readappears in 42% of workflows, enabling workflows to inspect CI resultsTool & MCP Server Patterns
Most Used MCP Servers
githubsafeoutputsplaywrightserenatavilyagenticworkflowsmcpscriptsqmd*Counts exceed 178 because some workflows configure multiple named instances of the same server type.
Playwright (27%) and Serena (14%) are notably popular, showing that a significant portion of workflows need either web scraping capabilities or deep code analysis via LSP.
Engine Distribution
Historical Trends
15-Day Growth Chart (2026-03-11 → 2026-03-26)
Key trend observations:
Interesting Findings
Template uniformity is extreme: 80.9% of files fall in a single 25 KB size band (50–75 KB), and every single lock file has exactly 2 jobs. The harness generator produces highly standardized output.
workflow_dispatch is nearly universal (92.1%): Almost every automated workflow can also be triggered manually, providing an important escape hatch for debugging and on-demand runs.
Concurrency is 100%: Every workflow configures a concurrency group, and 97.2% use
cancel-in-progress: true— preventing queue build-up and ensuring only the latest run executes for a given context.The platform is primarily an audit machine: 45 workflows post to the
auditsdiscussion category, making it by far the dominant output destination. The entire system seems designed to continuously monitor and audit the repository's health.Playwright adoption at 27%: More than 1 in 4 workflows uses a browser automation MCP server. This suggests workflows frequently need to interact with web-rendered content or external web services, beyond what REST APIs expose.
Codex growing fast (+73% in 15 days): OpenAI Codex engine adoption nearly doubled (11 → 19) in the analysis window while other engines stayed flat — indicating active expansion of Codex-powered workflows.
Recommendations
Consolidate cron schedules: Several cron patterns cluster at UTC business hours (9am–3pm weekdays), which could lead to resource contention. Spreading them across off-peak hours or using GitHub's built-in jitter mechanisms would improve reliability.
Review timeout outliers: 21 workflows have timeouts > 30 minutes (max: 180 min). These long-running workflows risk consuming significant runner minutes and should be audited to verify they actually need extended execution time.
Monitor Codex growth: The rapid Codex engine expansion (+73% in 2 weeks) warrants attention. Validate that newly added Codex workflows have appropriate testing coverage and aren't duplicating existing Claude/Copilot workflows.
Evaluate the 4 minimal workflows: The 4 files under 30 KB (test-workflow, codex-github-remote-mcp-test, example-permissions-warning, firewall) are significantly simpler than the rest. Confirm they are intentional minimal examples, not incomplete configurations.
Track Gemini adoption: With only 1 Gemini workflow, consider whether this is an intentional experiment or a gap in multi-model coverage.
Methodology
/tmp/gh-aw/cache-memory/— scripts persisted for reuse, history tracked since 2026-02-21.github/workflows/*.lock.ymlReferences:
Beta Was this translation helpful? Give feedback.
All reactions