{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Runtime {{ resultsReady ? computation.values.runtime_label : '—' }} Runners {{ resultsReady ? computation.values.runner_count : '—' }} Review {{ resultsReady ? computation.values.review_state : '—' }}
Use the stable check name expected by branch protection.
Choose the ecosystem whose version axis the workflow will test.
Examples: 20, 22, 24 or 3.12, 3.13, 3.14.
Typical hosted labels include ubuntu-latest, macos-latest, and windows-latest.
Prefer a lockfile-aware, reproducible install command.
Use the same command your project treats as its CI acceptance check.
Confirm that the selected action supports the generated cache input.
Choose a whole number from 1 through 360.
min
Leave off when you need the full compatibility picture from every job.
{{ fail_fast ? 'Cancel after required failure' : 'Run the full matrix' }}
Pull requests
Recommended for ordinary build-and-test workflows.
{{ contents_read ? 'Contents read enabled' : 'Permission block omitted' }}
A blank value keeps the neutral ci.yml default.
Letters, numbers, underscores, and hyphens are preserved.
Use owner/repository@ref syntax and review third-party actions before running them.
The same key is used in matrix expressions and setup-action inputs.
Blank uses only the preset version and cache inputs.
Use repository-relative dependency files for cache invalidation.
Enter one path per line when more than one cache location is required.
This changes shell-step context, not checkout location.
Filters are emitted only when the Pushes trigger is enabled.
Leave blank when runtime and runner axes fully describe the test plan.
Every value multiplies the base runner/runtime grid.
Compatible rows augment existing jobs; incompatible rows add new jobs.
Use the emitted matrix keys shown in the result ledger.
The neutral value 0 leaves concurrency uncapped.
jobs 
{{ computation.values.workflow_yaml }}

The chart renderer is unavailable. Runner counts remain available in the matrix plan.

Runner{{ computation.values.version_key }}Extra axisOriginExperimentalCopy
{{ row.runner }}{{ row.version }}{{ row.extra }}{{ row.origin }}{{ row.experimental ? 'Yes' : 'No' }}
CheckStatusDetailCopy
{{ row.check }}{{ row.status }}{{ row.detail }}
GitHub Actions Cache Config Generator Generate GitHub Actions cache YAML from ecosystem and lockfile choices, with ordered restore keys and security checks before you commit it.
CI Runner Capacity Calculator Estimate CI runner slots from workload minutes and peak demand, then check utilization headroom and queue-clear time against platform caps and retry load.
Test Shard Runtime Calculator Estimate CI test shard wall time and runner minutes from suite work, setup overhead, split balance, efficiency, and job concurrency.
CI Failure Log Analyzer Find actionable clues in a failed CI log, map them to pipeline stages, and mask common secret patterns before sharing the evidence.

A compatibility promise becomes expensive as soon as it spans more than one operating system or runtime version. A GitHub Actions matrix keeps that promise visible in one job definition, then expands the selected values into separate jobs. Two runner labels and three runtime versions therefore describe six tests without six copied job blocks.

The useful unit is a combination: one value from every active axis. Runner and runtime are common axes; a database, package manager, architecture, or shard can be a third. Each new axis multiplies the work, so it should represent a real support boundary or a failure mode that the other jobs cannot expose.

Base grid
Every Cartesian combination of the ordinary axis values.
Exclude rule
A partial match that removes unsupported or deliberately skipped base combinations.
Include rule
An object that augments compatible base jobs or creates a separate job when it cannot be merged without replacing an axis value.

Coverage and feedback speed pull in opposite directions. A broad grid catches platform drift, while a smaller grid returns pull-request results sooner and uses fewer runner minutes. A practical design often tests the full supported set on one event and reserves experimental combinations for deliberate include rows. Concurrency limits change how many jobs run at once, not how many jobs exist.

Generated YAML is still a draft. Action references, runner labels, setup inputs, lockfiles, shell commands, repository permissions, and branch-protection check names all depend on the repository that will run it. A syntactically plausible workflow can still fail immediately or grant more access than intended.

Matrix results also have a narrow meaning. A green run confirms only the combinations and commands that actually executed. It does not prove compatibility with omitted environments, validate a moving -latest runner image, or show that an unused include or exclude rule expresses the repository's policy correctly.

How to Use This Tool:

Start with the smallest grid that represents the support policy, then add exceptions and execution controls only where they change the evidence.

  1. Choose Runtime ecosystem, then replace the suggested versions, install command, and test command with values the repository already uses.
  2. Enter the Runner labels and runtime versions. Add an Extra matrix axis only when every listed value deserves a separate job.
  3. Select triggers, repository permission, dependency cache, timeout, fail-fast behavior, and any parallelism cap. At least one trigger must remain enabled.
  4. Add exception rows as comma-separated key=value pairs, one object per line. Use the emitted axis keys and correct malformed rows before copying the YAML.
  5. Read Review checks and compare the Matrix plan with the intended support list. Test the saved workflow manually before requiring its check in branch protection.

Interpreting Results:

The planned-job count is the first result to inspect. It includes retained base combinations and any separate jobs introduced by include rules. The runner distribution should match the intended platform emphasis rather than merely look balanced.

  • Ready means the local rules produced a workflow without a flagged repository decision. It is not a GitHub execution result.
  • Review identifies choices such as fail-fast cancellation, mutable action tags, exception rules, disabled caching, or an omitted explicit permission block.
  • A blocked matrix over 256 planned jobs must be reduced or split before YAML is produced. A matrix emptied by exclude rules is also invalid.

Technical Details:

Matrix expansion begins with unique runner and runtime values. An optional third axis joins the same product. Exclude objects are tested against the base rows by exact string equality for every key they contain. Include objects are then applied in entry order to compatible retained base rows; an object that cannot merge without replacing an axis value becomes a new row.

Formula Core:

The ordinary grid is a Cartesian product. After exclusions and additions, the final count is:

Jbase = R×V×A Jfinal = Jbase −E+N

Here R is the runner count, V the runtime-version count, and A the extra-axis count; when no extra axis exists, A is 1. E is the number of base rows removed by exclude rules, and N is the number of include objects that become new rows. Includes that only add properties to existing rows do not increase the count.

Rule Core:

Stage Exact behavior Boundary
Normalize axes Split on commas or line breaks, trim values, and remove case-insensitive duplicates while preserving the first spelling. 1 to 16 runners, 1 to 32 runtimes, and 0 to 16 extra-axis values.
Apply exclusions Remove each base row that matches every key present in an exclude object. At most 64 exclude objects; removing every row is invalid.
Apply inclusions Merge properties into compatible retained base rows; otherwise append a new combination. Later include objects may update properties added by earlier ones on base rows. At most 64 include objects.
Emit workflow Write triggers, optional read-only contents permission, job strategy, setup and cache steps, then install and test commands. 1 to 360 timeout minutes; 0 omits max-parallel, while 1 to 256 emits it.
Accept plan Return YAML, plan rows, runner counts, and review findings. Jfinal must be 1 to 256.

Preset setup values cover Node.js, Python, Go, Java, and a custom runtime path. Overrides are normalized into safe workflow filenames, job identifiers, and axis keys. Manual caching emits an explicit cache step only when a cache path exists; setup-action caching instead passes the preset cache input and optional dependency paths to the setup action.

An include row with experimental=true also enables per-job continue-on-error through the matrix value. Fail-fast remains independent: when enabled, a failure in a required job may cancel queued or running jobs, while a failed experimental job does not cause that cancellation.

Accuracy and Security Notes:

The review is deterministic and local, but it does not parse the generated YAML with GitHub or inspect the repository. Confirm action inputs against the selected action release, prefer immutable commit references where policy requires them, verify lockfile and cache paths, and keep permissions at the least access the job needs.

Runner labels ending in -latest can move to newer images. Re-run representative jobs after image transitions, and pin an explicit image label when reproducibility matters more than automatically receiving the newest hosted environment.

References: