📊 Agentic Workflow Lock File Statistics - December 26, 2025 #7776
Closed
Replies: 1 comment
-
|
This discussion was automatically closed because it was created by an agentic workflow more than 3 days ago. |
Beta Was this translation helpful? Give feedback.
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
This comprehensive analysis examines all agentic workflow lock files (
.lock.yml) in the.github/workflows/directory, revealing patterns in triggers, safe outputs, structural complexity, and resource usage across the repository's automated agent workflows.Key Findings:
workflow_dispatchFull Report
File Size Distribution
Size Statistics:
example-permissions-warning.lock.yml(28.8 KB)copilot-session-insights.lock.yml(133.7 KB)The distribution shows that agentic workflows are substantial in size, with the vast majority falling into the 50-100 KB range. This reflects the complexity of agent prompts, tool configurations, and multi-stage job orchestration.
Trigger Analysis
Most Popular Triggers
Key Observations:
workflow_dispatch, allowing on-demand executionCommon Trigger Combinations
The most popular pattern (61% of workflows) is scheduled + manual, allowing regular automated runs with the flexibility to trigger on-demand.
Schedule Patterns
0 14 * * 1-50 13 * * 1-50 11 * * 1-50 9 * * 1Schedule Analysis:
Safe Outputs Analysis
Safe Outputs Usage: 120 out of 124 workflows (96.8%) include safe outputs configuration, indicated by the presence of
GH_AW_SAFE_OUTPUTSenvironment variable.Safe outputs provide a security boundary that allows agents to propose GitHub API actions (create issues, discussions, comments, PRs) without direct write access. Instead, outputs are collected and processed by downstream jobs with appropriate permissions.
Safe Output Architecture
The safe outputs pattern in these workflows follows a consistent structure:
permissions: read-alland proposes actions via MCP tools/tmp/gh-aw/safeoutputs/outputs.jsonlAvailable Safe Output Types
Based on the MCP server configuration visible in workflows:
create_discussioncreate_issueadd_commentmissing_toolnoopSecurity Model: This architecture ensures agents cannot directly modify the repository or create unintended side effects, requiring explicit downstream approval for all write operations.
Structural Characteristics
Job Complexity
Job Structure Patterns:
Most workflows follow a multi-stage pipeline:
Timeout Configurations
The 10-minute timeout is standard for agent execution, with 15-minute timeouts for workflows needing additional processing time.
Concurrency Patterns
All analyzed workflows use concurrency groups to prevent parallel executions:
Common Patterns:
gh-aw-${{ github.workflow }}- Workflow-level lockinggh-aw-${{ github.workflow }}-${{ github.event.issue.number }}- Issue-specific lockinggh-aw-${{ github.workflow }}-${{ github.event.pull_request.number }}- PR-specific lockingThis ensures that only one instance of an agent workflow runs at a time per context (workflow, issue, or PR).
Permission Patterns
Workflow-Level Permissions
Analysis of
permissions:blocks shows a security-conscious approach:permissions: {}): Used at workflow level in 241 instancespermissions: read-all): Only 2 instances, primarily for agent jobsJob-Level Permissions
Typical permission patterns by job type:
contents: read,issues: readcontents: read,issues: writeread-all(for safe outputs pattern)discussions: writeissues: writeissues: write,pull-requests: writeSecurity Principle: Workflows follow the principle of least privilege, with the agent job having read-all access but no write permissions, while output processing jobs have minimal write permissions only for their specific action.
Tool & MCP Patterns
Most Used MCP Servers
GitHub MCP Dominance: The GitHub MCP server is used in 93.5% of all tool configurations, reflecting these workflows' primary purpose of GitHub-centric automation and analysis.
Tool Usage Patterns
Based on analysis of workflow steps, the most common tool patterns include:
Average Lock File Profile
Based on statistical analysis, a typical .lock.yml file in this repository has:
Interesting Findings
1. Consistent Security Architecture
All workflows follow a remarkably consistent security pattern with the safe outputs architecture, demonstrating a mature approach to agent security. The separation between agent execution (read-only) and action taking (write permissions) is universal.
2. Staggered Schedule Distribution
The unique minute values in cron schedules (e.g.,
47 14,19 9,56 11) suggest intentional load distribution to avoid thundering herd problems when multiple workflows would otherwise trigger simultaneously at round-number times.3. Weekday Business Hours Bias
The overwhelming preference for weekday scheduling (
1-5in cron expressions) and business hour timing indicates these workflows are designed to align with human work patterns, likely for timely notification delivery and responsiveness.4. Job Complexity Distribution
The maximum of 56 steps in a single job and average of 12.8 steps indicates sophisticated multi-step orchestration within individual jobs, not just across jobs.
5. Workflow Dispatch as Standard
With 86% of workflows supporting manual triggering, the repository has embraced on-demand execution as a first-class feature, enabling easy testing, debugging, and ad-hoc runs.
6. Size Consistency
The tight clustering around 50-100 KB suggests standardized workflow templates and patterns, with outliers likely having specialized prompts, additional tool configurations, or extended documentation.
Historical Context
This is the first comprehensive statistical analysis of the repository's lock files. Future analyses will track:
Baseline Metrics (Dec 26, 2025):
Recommendations
1. Documentation of Standard Patterns
With such consistent patterns emerging (safe outputs, concurrency groups, permission models), creating template workflows or documentation could accelerate new workflow development and maintain consistency.
2. Schedule Optimization Review
Review the 86 scheduled workflows to ensure timing still aligns with actual usage patterns. Consider consolidating workflows with similar schedules if they perform related tasks.
3. Size Outlier Investigation
The 19 workflows >100 KB warrant review to determine if they contain duplicated logic, excessive prompts, or if they could benefit from modularization.
4. MCP Server Usage Analysis
With Playwright used in 210 instances, consider dedicated documentation or examples for browser automation patterns. The light usage of arxiv and deepwiki suggests opportunities for broader research-agent capabilities.
5. Timeout Standardization
The split between 10 and 15-minute timeouts could be standardized based on empirical runtime data to optimize cost and reliability.
6. Trigger Combination Patterns
The diversity in trigger combinations (20+ unique patterns) suggests potential for standardization. Common patterns could be documented as reference architectures.
Methodology
.github/workflows/*.lock.yml/tmp/gh-aw/cache-memory/lockfile-stats/Analysis Scripts Preserved
The following scripts have been saved to cache memory for future reuse:
collect_all_data.sh- Bash-based data extractionanalyze_lockfiles.py- Comprehensive Python analysisanalysis_results.json- Structured output dataThese scripts can be reused for future trend analysis and comparison.
References:
/tmp/gh-aw/cache-memory/lockfile-stats/data/analysis_results.json.github/workflows/Beta Was this translation helpful? Give feedback.
All reactions