📊 Agentic Workflow Lock File Statistics - December 22, 2025 #7270
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.
-
Overview
This comprehensive statistical analysis examined 122 agentic workflow lock files (
.lock.yml) in the.github/workflows/directory of the githubnext/gh-aw repository. The analysis reveals consistent patterns in workflow design, with nearly all workflows supporting flexible triggering mechanisms and standardized structural characteristics.Key Findings:
Full Report
File Size Distribution
Overview Statistics
Size Distribution
Analysis: The lock files show remarkable consistency in size, with 95.9% falling in the 100-500 KB range. This uniformity suggests standardized workflow structures across the repository. Only 3 files exceed 500 KB: poem-bot.lock.yml, incident-response.lock.yml, and org-wide-rollout.lock.yml, indicating more complex multi-job workflows with extensive agent instructions.
Outliers
Smallest Files (under 200 KB):
These smaller files likely represent simplified workflows or specialized testing scenarios.
Largest Files (over 500 KB):
Trigger Analysis
Most Popular Triggers
Analysis: The near-universal presence of
issues(98.4%) andpull_request(95.9%) triggers indicates that most agentic workflows are designed to respond to repository activity. The high adoption ofworkflow_dispatch(84.4%) enables manual execution for testing and on-demand operations. Scheduled workflows (68.0%) handle recurring tasks like daily reports and maintenance.Common Trigger Combinations
Insight: The dominant pattern (59.8%) combines scheduled execution with manual triggering, providing both automation and flexibility. This pattern is ideal for periodic analysis workflows that may also need ad-hoc execution.
Schedule Patterns
Most common cron schedules (top 10):
0 14 * * *0 13 * * *0 11 * * *0 9 * * 10 0,6,12,18 * * *0 9 * * 1-50 16 * * 1-50 15 * * 1-50 10 * * 1-50 */6 * * *Analysis: Schedules are distributed throughout the day to avoid resource contention. Most workflows run daily (47 workflows) during business hours UTC (9 AM - 4 PM), with some running multiple times per day (4-6 hour intervals) for more frequent monitoring.
Structural Characteristics
Job Complexity
Job Distribution:
Analysis: The majority of workflows (45.1%) have exactly 6 jobs, suggesting a standardized structure likely consisting of: activation, detection, agent execution, safe_outputs, conclusion, and cache update jobs.
Most Complex Workflows
By Step Count:
By Job Count:
Average Lock File Structure
Based on statistical analysis, a typical
.lock.ymlfile has:Permission Patterns
Most Common Permissions
Analysis: All workflows read repository contents (425 occurrences). Write permissions are strategically granted:
Permission Distribution
Security Insight: All workflows use empty top-level permissions (
permissions: {}), then grant specific permissions at the job level. This follows the principle of least privilege, ensuring each job only has the permissions it needs.Timeout Patterns
Analysis: The distribution centers around 10-20 minutes (93.3% of timeouts), with 10, 15, and 20 minutes being nearly equal. This suggests careful tuning based on job type:
Tool & Integration Patterns
GitHub Actions Usage
Analysis: Nearly all workflows (98.4%) use
actions/github-scriptfor JavaScript-based GitHub API interactions. Half the workflows (50%) use caching to persist data between runs, likely for historical analysis and performance optimization.MCP GitHub Tools
Based on the
mcp__github__*tool pattern analysis, workflows extensively use the GitHub MCP server for:The GitHub MCP server is the dominant integration, appearing in virtually all workflows as the primary interface to repository data.
Safe Outputs Analysis
Safe outputs enable agentic workflows to interact with the repository in controlled ways. Analysis of the permission patterns reveals:
Common Safe Output Types
Based on write permissions granted:
Pattern: Most workflows (221) can create discussions for reporting, while 230 can create/update issues for tracking work items. PR automation is enabled in 205 workflows for code review and collaboration.
Interesting Findings
1. Standardized Workflow Architecture
The remarkable consistency in file sizes (95.9% within 100-500 KB) and job counts (45.1% with exactly 6 jobs) suggests a mature, standardized workflow architecture. This standardization enables:
2. Balanced Triggering Strategy
The dominant pattern of
schedule + workflow_dispatch(59.8%) reflects a balanced approach:3. Security-First Permission Model
Every workflow implements job-level permissions rather than workflow-level permissions:
permissions: {}(100% of workflows)This architecture minimizes attack surface and follows security best practices.
4. Distributed Scheduling
Scheduled workflows are temporally distributed throughout the day with scattered minute values (e.g., 48, 47, 46) to avoid all workflows starting simultaneously at the top of the hour. This prevents:
5. Complexity Concentration
While most workflows are standardized, a few outliers handle exceptional complexity:
These workflows represent the upper bound of agentic workflow capabilities in the repository.
Historical Trends
Comparing with previous analysis from 2025-12-13:
Trend Analysis:
Recommendations
Based on the statistical analysis, here are recommendations for workflow authors and maintainers:
1. Follow the Standard Pattern
The 6-job structure with ~11 steps per job has emerged as the standard for good reason. New workflows should adopt this pattern:
2. Use Standard Timeouts
Align with the dominant timeout patterns:
3. Implement Scatter Scheduling
When adding scheduled workflows, use scattered minute values (e.g., 37, 42, 51) rather than top-of-hour (00) to distribute load.
4. Apply Granular Permissions
Continue the security-first approach:
5. Optimize File Size
Workflows over 500 KB should be reviewed for:
6. Cache Strategically
With 50% of workflows using cache, consider caching for:
Methodology
Data Collection
.lock.ymlfiles in.github/workflows/Analysis Techniques
Cache Memory Usage
Analysis scripts and results saved to
/tmp/gh-aw/cache-memory/:/tmp/gh-aw/cache-memory/scripts/- Reusable analysis scripts/tmp/gh-aw/cache-memory/data/- Historical data and current results/tmp/gh-aw/cache-memory/data/analysis-2025-12-22.json- Comprehensive analysis dataLimitations
Conclusion
The githubnext/gh-aw repository demonstrates a mature, standardized approach to agentic workflows. With 122 workflows averaging 396 KB and following consistent structural patterns, the ecosystem balances automation (68% scheduled), flexibility (84% manual dispatch), and responsiveness (98% issue-driven).
The dominant 6-job architecture with 10-20 minute timeouts and granular permissions reflects thoughtful design informed by operational experience. The increase in scheduled workflows (+10.7% in 9 days) and average file size (+7.5%) suggests continued evolution toward greater automation and capability.
This statistical foundation provides a baseline for monitoring workflow health, identifying optimization opportunities, and guiding new workflow development in the repository.
References:
/tmp/gh-aw/cache-memory/data/analysis-2025-12-22.jsonBeta Was this translation helpful? Give feedback.
All reactions