GitHub Actions Generator
Assemble a continuous integration workflow for your repository
-
1Enter data
Enter content, paste text or load a file from disk. -
2Click the button
The tool will immediately process your data in the browser. -
3Get the result
Copy the finished text or save the file to your device.
return "Result ready in 0.1s";
}
Rate this tool:
Related tools
Other tools you may find usefulGitHub Actions generator - a CI workflow in one YAML file
The GitHub Actions generator builds a continuous integration workflow file for a repository on GitHub. Set the run name, the branches, the PHP and Node versions and pick the steps, and you get YAML ready for the .github/workflows directory - with a code checkout, environment setup, dependency caching and test runs.
What a workflow is made of
A workflow file describes when and what GitHub should run. Four blocks form its skeleton:
| Key | Role | What the generator puts in |
|---|---|---|
name | run label in the Actions tab | the name from the form |
on | run triggers | push, pull_request on the chosen branches and workflow_dispatch |
jobs | jobs and their machine | a single build job on runs-on: ubuntu-latest |
steps | the steps inside a job | checkout, setup, cache, install, tests, lint |
The first step is always actions/checkout@v4 - without checking out the repository no later step can reach the code. After that the generator adds only what you tick.
How to build and run the workflow
- Enter a workflow name and comma-separated branches - they go into the
onblock forpushandpull_request. - Give a PHP version (you get a
shivammathur/setup-php@v2step) and/or a Node version (actions/setup-node@v4with npm cache). An empty field skips that ecosystem. - Tick Composer install, npm install, test runs and lint. The Example button loads a typical set for a Laravel plus front-end project.
- Copy the result and save it as
.github/workflows/ci.ymlin the repository root. - Commit and push - GitHub runs the workflow right away and the result shows up in the Actions tab. You can also start it by hand thanks to
workflow_dispatch.
Triggers: when the workflow starts
The on block decides what launches a run. The generator inserts push and pull_request limited to the chosen branches, so tests run on every push and on every pull request before a merge. It also adds workflow_dispatch - the "Run workflow" button in the GitHub UI for an on-demand run. GitHub also knows schedule (recurring runs in cron syntax), handy for nightly tests or refreshing dependencies; add that entry by hand in the generated file.
Dependency caching shortens the run
Installing packages can eat most of a run. The actions/setup-node@v4 step with cache: npm restores the npm directory on its own. For Composer the generator adds a separate actions/cache@v4 keyed on a hash of composer.lock - as long as the dependencies do not change, GitHub restores them from the cache instead of downloading them again. It is the same idea we describe in the GitLab CI generator, only in GitHub syntax.
Secrets instead of passwords in the file
${{ secrets.NAME }}. GitHub substitutes them on the fly and masks them in the logs.The generator deliberately puts no secrets in the output. The test and install steps use plain commands only, and you add the places for tokens (for a deploy or a package publish, say) yourself, reaching for the secrets context.
GitHub Actions versus other CI systems
A GitHub Actions workflow lives in the repository and starts from GitHub's own events. If you host code elsewhere, the Jenkinsfile generator helps with Jenkins, or a GitLab configuration. The project itself often needs a build image too - the Dockerfile generator covers that. Before you push the file to the repository, run it through the YAML validator, because in this format one space of indentation changes the structure.
Frequently asked questions
Where do I save the generated file?
In the .github/workflows/ directory at the repository root, with a .yml or .yaml extension. The file name is free - GitHub runs every workflow found in that directory. The label in the name block is a separate thing: it appears in the Actions tab but need not match the file name.
Why do the actions all use @v4?
Pinning to a major, such as actions/checkout@v4, tells GitHub to take the latest release from that branch. An old @v2 may be retired and warns about a deprecated Node in the runner. The exception is shivammathur/setup-php@v2 - a community action whose current major is still v2, so that pin is correct.
How do I use a token or password safely?
Add the value in the repository settings (Settings -> Secrets and variables -> Actions) and reference it in a step through ${{ secrets.NAME }}. The secret never appears in the code or the logs - GitHub masks it automatically. For deploys from a fork use environments with a protection rule, because a pull request from an outside repository gets no secrets by default.
Is GitHub Actions free?
Public repositories get free minutes on the standard GitHub runners. Private repositories get a monthly allowance that depends on the plan, and once it runs out a run is billed per minute used. Linux runners count the cheapest, Windows and macOS with a multiplier.
How do I add a matrix to test several PHP versions at once?
In the job add a strategy.matrix with a list of versions, for example php: ['8.2', '8.3', '8.4'], and in the setup step use php-version: ${{ matrix.php }}. GitHub then runs the job separately for each value. This generator makes a single build job; you add the matrix in the generated file.