📊 Lockfile Statistics Analysis - February 2026

[github-actions[bot]]

This comprehensive analysis examines all 149 .lock.yml files in the .github/workflows/ directory to identify usage patterns, structural characteristics, and interesting trends in agentic workflow configurations.

Executive Summary

• Total Lock Files: 149
• Total Size: 9.2 MB (9,623,924 bytes)
• Average File Size: 63.1 KB (64,590 bytes)
• Analysis Date: February 2, 2026
• Repository: githubnext/gh-aw

Key Findings:

• 100% of workflows use concurrency groups for safe parallel execution
• 87.9% support manual triggering via workflow_dispatch
• 69.8% run on scheduled intervals (daily, weekly, or custom schedules)
• 94.6% use the lightweight noop safe output for status reporting
• GitHub MCP server is used in 3,640 tool references across all workflows

File Size Distribution

Size Range	Count	Percentage
< 10 KB	0	0.0%
10-50 KB	11	7.4%
50-100 KB	136	91.3%
> 100 KB	2	1.3%

Statistics:

• Smallest: codex-github-remote-mcp-test.lock.yml (23.6 KB)
• Largest: smoke-claude.lock.yml (105.8 KB)
• Median Range: 50-100 KB (91.3% of all workflows)

The overwhelming concentration in the 50-100 KB range suggests a standardized workflow structure with consistent agent configuration patterns.

Trigger Analysis

Most Popular Triggers

Trigger Type	Count	Percentage	Use Case
workflow_dispatch	131	87.9%	Manual execution, testing, ad-hoc runs
schedule	104	69.8%	Automated daily/weekly monitoring
pull_request	14	9.4%	PR analysis and validation
issues	13	8.7%	Issue triage and automation
push	1	0.7%	Continuous integration

Key Insight: The vast majority of workflows support both manual triggering (87.9%) and scheduled execution (69.8%), indicating a hybrid automation approach that balances scheduled monitoring with on-demand analysis.

Schedule Patterns

The most common schedule patterns show workflows distributed throughout the workday:

Schedule (Cron)	Count	Description
0 14 * * 1-5	4	Daily at 2:00 PM (weekdays)
0 13 * * 1-5	4	Daily at 1:00 PM (weekdays)
0 11 * * 1-5	4	Daily at 11:00 AM (weekdays)
0 9 * * 1-5	2	Daily at 9:00 AM (weekdays)
0 */6 * * *	1	Every 6 hours
0 */4 * * *	1	Every 4 hours

Total Unique Schedules: 89 different cron patterns

Pattern Analysis:

• Weekday-only schedules dominate (most use 1-5 for Monday-Friday)
• Peak scheduling hours: 9 AM - 6 PM UTC
• Staggered execution times prevent resource contention
• Some workflows run on specific days (weekly reports on Mondays/Sundays)

View All Schedule Patterns (89 unique schedules)

0 14 * * 1-5 (4 workflows)
0 13 * * 1-5 (4 workflows)
0 11 * * 1-5 (4 workflows)
0 9 * * 1-5 (2 workflows)
0 7 * * 1-5 (2 workflows)
0 16 * * 1-5 (2 workflows)
0 15 * * 1-5 (2 workflows)
0 10 * * 1-5 (2 workflows)
... and 81 more unique patterns

Safe Outputs Analysis

Safe Output Distribution

Type	Workflows	Percentage	Primary Use
noop	141	94.6%	Status logging, completion signals
add-comment	25	16.8%	PR/issue feedback
create-discussion	0	0.0%	Community discussions
create-issue	0	0.0%	Issue creation

Key Findings:

• Noop dominance: 94.6% of workflows use the noop tool for transparency logging
• Comment-based feedback: 25 workflows (16.8%) add comments to PRs or issues
• No discussion creation: None of the current workflows create GitHub Discussions (this analysis will be the first!)
• Zero multi-output workflows: No workflows combine multiple safe output types

Example Workflows Using add-comment:

• smoke-codex
• changeset
• mergefest

The widespread use of noop indicates that most workflows perform analysis and logging rather than creating new GitHub resources.

Structural Characteristics

Job Complexity

• Average Jobs per Workflow: ~5.03 jobs
• Average Steps per Workflow: ~5.17 steps
• Maximum Steps in Single Job: Varies by complexity
• All workflows: Use standardized job structure

Standard Job Pattern (found in 100% of workflows):

1. detection - Workflow triggering logic
2. activation - Conditional execution control
3. agent - Main agent execution
4. safe_outputs - Safe output generation
5. conclusion - Workflow summary

Optional Jobs (frequency):

• pre_activation (52 workflows) - Pre-flight checks
• update_cache_memory (65 workflows) - Cache persistence
• push_repo_memory (24 workflows) - Repository memory updates
• upload_assets (22 workflows) - Artifact management

Average Lock File Structure

Based on statistical analysis, a typical .lock.yml file has:

• Size: ~63 KB
• Jobs: 5 core jobs (detection, activation, agent, safe_outputs, conclusion)
• Triggers: workflow_dispatch + schedule (or event-based)
• Timeout: ~17 minutes average
• Runner: ubuntu-slim (preferred) or ubuntu-latest
• Concurrency: Workflow-specific group with auto-cancellation
• Safe Outputs: noop for transparency logging

Runner Distribution

Runner Type	Usage Count	Percentage
ubuntu-slim	506	56.2%
ubuntu-latest	394	43.8%

Total runner instances: 900 (across all jobs in all workflows)

Key Insight: The ubuntu-slim runner is preferred (56.2%), likely for faster startup times and reduced resource consumption in agent workloads.

Tool & MCP Patterns

Most Used MCP Servers

MCP Server	References	Primary Purpose
github	3,640	GitHub API operations (issues, PRs, repos, commits)
playwright	210	Browser automation, web scraping, testing
deepwiki	6	Deep Wikipedia research and citations
arxiv	6	Academic paper search and analysis
tavily	4	Web search and research
microsoftdocs	2	Microsoft documentation access
markitdown	2	Markdown conversion and processing
ast-grep	2	Code structure analysis

Dominant MCP: The GitHub MCP server accounts for ~94% of all MCP references, reflecting the repository-centric nature of these workflows.

Browser Automation: Playwright MCP (210 references) indicates significant web interaction capabilities across workflows.

Timeout Patterns

• Average Timeout: 16.6 minutes
• Minimum Timeout: 5 minutes
• Maximum Timeout: 180 minutes (3 hours)
• Total Timeout Samples: 565 (some workflows have per-job timeouts)

Distribution Insight: The 16.6-minute average suggests most agentic workflows complete in under 20 minutes, balancing thoroughness with responsiveness.

Concurrency & Resource Management

• Workflows with Concurrency Groups: 149 (100%)
• Workflows Using Cache: 67 (45.0%)
• Auto-cancel In-Progress: ~10 workflows explicitly configure this

Concurrency Group Patterns:

1. gh-aw-${{ github.workflow }} (117 workflows) - Per-workflow serialization
2. gh-aw-${{ github.workflow }}-${{ github.event.issue.number }} (13 workflows) - Per-issue serialization
3. gh-aw-${{ github.workflow }}-${{ github.event.pull_request.number }} (14 workflows) - Per-PR serialization

Cache Usage: 45% of workflows use GitHub Actions cache for:

• Agent state persistence
• Dependency caching
• Historical data tracking

Workflow Naming Patterns

Top workflow name prefixes by frequency:

Prefix	Count	Category
daily	25	Scheduled daily monitors
smoke	6	Integration tests
copilot	6	Copilot-specific workflows
test	5	Testing workflows
security	5	Security scanning
workflow	4	Workflow management
issue	4	Issue automation
go	3	Go language workflows
github	3	GitHub operations
agent	2	Agent-specific tasks

Naming Convention: Clear, descriptive prefixes (daily-, test-, security-) make workflow purposes immediately apparent.

Interesting Findings

1. Perfect Concurrency Adoption: 100% of workflows implement concurrency groups, demonstrating excellent resource management and preventing duplicate executions.

2. Hybrid Scheduling Model: The combination of scheduled triggers (69.8%) and manual dispatch (87.9%) enables both automated monitoring and ad-hoc analysis, providing flexibility without sacrificing automation.

3. Noop as Standard Practice: The overwhelming use of the noop safe output (94.6%) shows a mature transparency pattern where workflows always produce visible status, even when no other actions are needed.

4. Lightweight Runners Preferred: 56% preference for ubuntu-slim over ubuntu-latest suggests optimization for faster agent startup and reduced billing.

5. No Discussion Creation Yet: Despite the repository having 149 agentic workflows, none currently create GitHub Discussions, making this statistical analysis report the inaugural discussion!

6. Consistent Structure: The standardized 5-job pattern (detection → activation → agent → safe_outputs → conclusion) across all workflows suggests a well-established workflow framework.

7. Weekday-Focused Automation: Schedule patterns heavily favor weekday execution (Monday-Friday), aligning with business hours and active development periods.

8. MCP Server Ecosystem: 8 different MCP servers in use, with GitHub MCP dominating (94% of references), but showing diversity in capabilities (browser automation, research, documentation).

Historical Trends

This is the first comprehensive lockfile statistics analysis. Future analyses will compare:

• Lock file count growth over time
• Average size trends (indicating feature additions or optimizations)
• New trigger patterns and safe output types
• MCP server adoption rates

Baseline Established: February 2, 2026

• 149 workflows
• 9.2 MB total
• 63 KB average size

Recommendations

Based on this analysis, here are suggested improvements and best practices:

1. Consider Discussion Creation: Only 0% of workflows create discussions. For audit reports, community updates, and comprehensive analyses, leveraging the create-discussion safe output could improve visibility.

2. Optimize Runner Selection: With ubuntu-slim showing 56% adoption, workflows still on ubuntu-latest could benefit from migration for faster startup times.

3. Cache Memory Expansion: Only 45% of workflows use caching. More workflows could benefit from cache memory for historical tracking and performance optimization.

4. Schedule Distribution: With 89 unique cron patterns, there's good time distribution, but some hours (10-14 UTC) are more crowded. Consider redistributing for even resource utilization.

5. Safe Output Diversity: Explore using create-issue for discovered problems and create-pull-request for automated fixes, expanding beyond the current noop/add-comment pattern.

6. Timeout Optimization: With an average of 16.6 minutes, some workflows might benefit from optimized timeouts based on actual execution patterns.

Methodology

• Analysis Tool: Bash scripts with AWK/sed/grep for YAML parsing
• Lock Files Analyzed: 149 (100% coverage)
• Cache Memory: Used for script persistence and historical data tracking
• Data Sources: .github/workflows/*.lock.yml
• Script Location: /tmp/gh-aw/cache-memory/scripts/
• Historical Data: /tmp/gh-aw/cache-memory/history/2026-02-02.json

Analysis Scripts Created:

• analyze_lockfiles.sh - Main analysis orchestrator
• extract_triggers.sh - Trigger and schedule extraction
• analyze_safe_outputs.sh - Safe outputs detailed analysis
• detailed_analysis.sh - Structural characteristic extraction
• final_stats.sh - Summary statistics generation

All scripts are persisted in cache memory for future analyses and reuse.

---

References:

• §21595203376

AI generated by Lockfile Statistics Analysis Agent

• expires on Feb 9, 2026, 3:10 PM UTC

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-02-09T15:10:39.969Z.

Closed by Workflow