forecast command from GitHub Actions Importer. The forecast step estimates the effort, resource usage, and feasibility of migrating Jenkins CI/CD pipelines to GitHub Actions before you convert them. By analyzing historical Jenkins run data, it predicts runner minutes, concurrency needs, and queue behavior so you can plan capacity and cost for GitHub-hosted or self-hosted runners.
- Data collection: extracts Jenkins metrics such as build durations, frequencies, job metadata, and queue labels.
- Usage prediction: analyzes the collected metrics to estimate GitHub Actions runner minutes, peak concurrency, and expected queue times.
- Reporting: produces logs, datasets of completed jobs, and human-readable forecast reports.
- Planning aid: provides actionable numbers to size runner pools, choose runner types, and estimate billing costs.
Usage
Run the forecast against your Jenkins instance. The command writes logs and the forecast report to the output directory you specify:tmp/forecast) contains:
- Logs of the forecast process
- A dataset of completed Jenkins jobs used for analysis
- One or more forecast reports summarizing resource and concurrency predictions
Key metrics included in the forecast report
The forecast report focuses on a concise set of metrics that drive migration planning. Use the table below to quickly understand each metric and why it matters.| Metric | What it measures | Why it matters |
|---|---|---|
| Job count | Total number of completed jobs analyzed | Helps validate dataset size and representativeness |
| Pipeline count | Number of unique pipelines (jobs) observed | Identifies breadth of workflows to migrate |
| Execution time | Time a runner spent executing a job (per-job and aggregated) | Direct input for calculating total runner minutes and cost |
| Queue time | Time jobs waited for a runner | Reveals need for higher concurrency or autoscaling |
| Concurrent jobs | Jobs running simultaneously over time | Determines peak runner count required |
| Per-queue metrics | Metrics broken down by Jenkins queue/label/node type | Useful when different queue types have different capacity or hardware |
How to interpret the numbers
- Execution time (total and percentiles): gives you expected monthly or yearly runner minutes. Multiply these by the per-minute price for the runner image you plan to use to estimate cost.
- Peak concurrency: informs how many simultaneous runners you should provide (self-hosted or GitHub-hosted concurrency limits).
- High queue time: indicates either not enough runners or uneven scheduling; consider autoscaling or redistributing workloads.
- Per-queue differences: prioritize migrating queues with predictable usage first; complex or highly variable queues may need capacity buffer or dedicated self-hosted runners.
Use the forecast results to size runner pools and estimate costs before migrating pipelines. Combine the forecasted runner minutes and peak concurrency with GitHub Actions pricing and your chosen runner types to prepare an accurate migration plan.
Example planning steps after a forecast
- Aggregate total runner minutes from the forecast for the migration window you care about (monthly, quarterly).
- Choose runner types (GitHub-hosted images or self-hosted hardware), and apply cost per-minute or infrastructure cost estimates.
- Evaluate peak concurrency to set a minimum runner pool or autoscaling policy.
- For queues with large variance or long-running jobs, consider isolating those onto dedicated self-hosted runners or throttling parallelism.
- Re-run forecasts periodically or after major pipeline changes to keep capacity planning accurate.
Links and references
- GitHub Actions billing documentation
- GitHub Actions Importer (project README) (reference for command usage and advanced options)