GitHub Actions Generator
Create a continuous integration workflow for your repository in a minute. Choose the language and versions, and the generator writes a workflow with the right setup action and dependency cache, lint, test and build steps, a version and operating-system matrix, a database service container for tests, an optional job that builds and pushes a Docker image to GitHub Container Registry, and secure defaults such as read-only permissions and cancelled outdated runs.
- Runs in your browser
- No sign-up
- Free to use
How to use GitHub Actions Generator
- Choose the language and versions to test.
- Adjust the install, lint, test and build commands.
- Pick triggers, services and Docker options.
- Save the file as .github/workflows/ci.yml.
GitHub Actions Generator features
Eight languages
Official setup actions with built-in dependency caching.
Matrix builds
Several versions and Linux, Windows and macOS.
Triggers
Push, pull requests, tags, schedule and manual runs.
Service containers
PostgreSQL, MySQL or Redis for integration tests.
Docker to GHCR
Buildx with cache and automatic tags, using GITHUB_TOKEN.
Secure defaults
contents: read permissions, concurrency, timeouts.
When to use GitHub Actions Generator
- Adding CI to a new repository.
- Testing a library on several language versions.
- Publishing container images on every release.
- Running integration tests against a real database.
GitHub Actions Generator FAQ
Where do I put the file?
In .github/workflows/ with a .yml extension, for example .github/workflows/ci.yml. GitHub picks it up on the next push.
How does caching work?
The setup actions cache the package manager’s downloads keyed by the lock file, so dependencies install quickly when they have not changed.
Why permissions: contents: read?
The workflow’s GITHUB_TOKEN gets only the rights it needs. The Docker job adds packages: write to push images.
When do scheduled runs happen?
At the cron time in UTC, on the default branch. GitHub may delay them and disables them after 60 days without repository activity.
How are Docker images tagged?
With the branch name, the version from tags such as v1.2.3, and the commit SHA, using docker/metadata-action.
Is anything uploaded?
No. The workflow is generated in your browser.
CI workflows on GitHub
GitHub Actions runs workflows defined in YAML files inside the repository. A typical CI workflow checks out the code, installs the language runtime, restores the dependency cache, installs dependencies, and runs linting, tests and a build on every push and pull request. Writing it from scratch means looking up the right setup action, inputs and syntax for each language.
The generator knows the official setup action for each language and the input that enables its cache: npm for Node.js, pip for Python, Maven for Java, Bundler for Ruby, and so on. Commands default to the conventional ones for the language and can be changed freely.
A matrix runs the job once per combination of language version and, optionally, operating system, with fail-fast disabled so one failure does not hide the others. A PostgreSQL, MySQL or Redis service container can run beside the tests, with health checks so tests only start when the database is ready, and the connection URL is passed to the test step.
For containerised apps, a second job builds the image with Buildx, uses the GitHub Actions cache for layers and pushes it to GitHub Container Registry, authenticated with the built-in GITHUB_TOKEN, so no registry password needs to be stored. It runs only after the tests pass and never for pull requests.
Security and efficiency defaults are included: the token is limited to reading the repository, outdated runs for the same branch are cancelled, and jobs time out after 20 minutes. For stricter supply-chain security, pin third-party actions to commit SHAs.