What triggers this workflow?

It triggers on pushing a Git tag that matches your pattern, such as v1.2.0. Pushing the tag with `git push origin v1.2.0` starts the run, builds artifacts, and publishes a GitHub Release for that tag.

Do I need a personal access token?

No. The workflow uses the automatically provided GITHUB_TOKEN, granted contents write permission, which is enough to create releases and upload assets in the same repository. No extra secret is required.

How are the release notes generated?

The release action sets generate_release_notes to true, so GitHub builds notes from the merged pull requests and commits since the previous tag. You can edit the published notes afterward in the Releases UI.

How do I mark a pre-release?

Enable the pre-release toggle and the workflow adds prerelease true, which flags the release so it is not shown as the latest stable version. This is useful for beta or release-candidate tags like v2.0.0-rc1.

Does this tool publish anything?

No. It only generates workflow YAML from your inputs in the browser. The actual release is created by GitHub when your workflow runs in your repository, and nothing here is uploaded.

GitHub Actions Release Workflow Builder

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

When you tag a version, you usually want the same things to happen every time: build the artifacts, attach them, and publish notes. This generator builds a GitHub Actions workflow that fires on a version tag, runs your build, auto-generates release notes from commit history, and uploads your assets to a GitHub Release.

How it works

The workflow listens on a push event filtered to tags matching your pattern. On a match it:

Checks out the full history so the changelog action can diff against the previous tag.
Runs your build command to produce the release artifacts.
Calls softprops/action-gh-release, which creates the release for the pushed tag, sets generate_release_notes: true, and uploads every file matching your asset globs.

It needs only the built-in GITHUB_TOKEN with contents: write permission — no personal access token.

Tips and notes

Use a tag pattern like v* so only version tags publish releases, not every tag.
Generated notes summarize merged pull requests since the last tag; write clear PR titles for clean changelogs.
Provide multiple asset globs (one per line) to attach binaries for several platforms in a single release.
For signed or checksummed assets, add a step before the release that produces the .sha256 files and include them in the globs.