GitHub Actions Generator

What this tool is used for

• Producing a starting workflow without remembering the trigger and job syntax.
• Getting a matrix or a runner declaration right for a language version set.
• Generating a workflow for a new repository consistently with existing ones.
• Producing a scaffold you then extend with real build steps.
• Checking the indentation structure a workflow requires.

Frequently Asked Questions

What is the difference between push and pull_request triggers?

`push` fires on commits to the listed branches; `pull_request` fires on the merge result, not the branch head. Enabling both on the same branch runs the workflow twice for a PR from the same repository — one of the most common sources of doubled CI minutes.

Which runner should I choose?

`ubuntu-latest` unless you need otherwise: it starts fastest and is billed at the base rate. macOS runners cost ten times more per minute and Windows twice, so a matrix across all three multiplies both the wall clock and the bill — worth it for a cross-platform library, wasteful for a web app.

What does the cache step actually save?

The dependency directory keyed by a hash of the lockfile — so an unchanged lockfile restores `node_modules` or `~/.cargo` instead of re-downloading. The key matters more than the path: keying on anything that changes every run means a cache that is always written and never hit.

Why pin actions to a version?

Because `@main` executes whatever that repository contains at the moment your job runs, including changes made after your last review. A tag is the minimum; a full commit SHA is what security guidance recommends, since a tag can be moved to point at different code.

How do secrets work in a workflow?

They are injected as `${{ secrets.NAME }}` and masked in logs. Two limits worth knowing: a `pull_request` from a fork gets no secrets at all, deliberately, and masking is string matching — a secret that gets base64-encoded or split across lines appears in the log in the clear.

Common errors and gotchas

• Indenting a key under the wrong level, which YAML accepts and Actions then ignores.
• Omitting a checkout step, so the job runs against an empty workspace.
• Granting broad token permissions by default rather than the minimum the job needs.
• Triggering on every push to every branch, which burns minutes and produces noise.
• Assuming secrets are available to workflows triggered from a fork, which they are not.