Top Related Projects
An Action to create releases via the GitHub Release API
Drafts your next release notes as pull requests are merged into master.
An action which manages a github release
Quick Overview
softprops/action-gh-release is a GitHub Action that simplifies the process of creating GitHub releases. It automates the release creation workflow, allowing developers to easily publish releases with customizable options directly from their CI/CD pipeline.
Pros
- Easy integration with existing GitHub Actions workflows
- Supports automatic asset uploading and release notes generation
- Highly customizable with various input parameters
- Works well with other popular GitHub Actions for a complete release process
Cons
- Limited to GitHub-specific releases (not suitable for other platforms)
- Requires careful configuration to avoid unintended releases
- May have a learning curve for users new to GitHub Actions
- Dependent on GitHub's API and infrastructure
Getting Started
To use the softprops/action-gh-release action in your workflow, add the following step to your .github/workflows/release.yml
file:
- name: Release
uses: softprops/action-gh-release@v1
if: startsWith(github.ref, 'refs/tags/')
with:
files: |
dist/**/*.tar.gz
dist/**/*.zip
body_path: ${{ github.workspace }}/CHANGELOG.md
draft: false
prerelease: false
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
This example creates a release when a new tag is pushed, uploads assets from the dist
directory, and uses the content of CHANGELOG.md
as the release notes. Adjust the configuration according to your project's needs.
Competitor Comparisons
An Action to create releases via the GitHub Release API
Pros of create-release
- Official GitHub action, potentially better long-term support
- Simpler setup for basic release creation
- Integrates well with other official GitHub actions
Cons of create-release
- Less flexible compared to action-gh-release
- Fewer customization options for release assets and metadata
- Limited support for pre-releases and draft releases
Code Comparison
action-gh-release:
- name: Release
uses: softprops/action-gh-release@v1
with:
files: |
dist/*.tar.gz
dist/*.zip
body_path: ${{ github.workspace }}/CHANGELOG.md
prerelease: ${{ contains(github.ref, '-rc') }}
create-release:
- name: Create Release
uses: actions/create-release@v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
tag_name: ${{ github.ref }}
release_name: Release ${{ github.ref }}
body: |
Changes in this Release
- First Change
- Second Change
action-gh-release offers more flexibility in specifying release assets and metadata, while create-release provides a simpler setup for basic release creation. action-gh-release allows for easier customization of pre-releases and draft releases, whereas create-release has more limited options in these areas. The code comparison demonstrates the difference in complexity and customization options between the two actions.
Drafts your next release notes as pull requests are merged into master.
Pros of Release Drafter
- Automatically generates release notes based on pull request labels and titles
- Allows customization of release note categories and content through configuration
- Supports draft releases, enabling review before publishing
Cons of Release Drafter
- Requires more setup and configuration compared to Action GH Release
- May not be suitable for projects with simple release processes
- Limited to GitHub-specific features and integrations
Code Comparison
Release Drafter configuration:
template: |
## What's Changed
$CHANGES
categories:
- title: '🚀 Features'
labels:
- 'feature'
- 'enhancement'
- title: '🐛 Bug Fixes'
labels:
- 'fix'
- 'bugfix'
- 'bug'
Action GH Release usage:
- name: Release
uses: softprops/action-gh-release@v1
if: startsWith(github.ref, 'refs/tags/')
with:
files: |
dist/*.tar.gz
dist/*.zip
Both tools aim to simplify the release process, but Release Drafter focuses on generating comprehensive release notes automatically, while Action GH Release provides a straightforward way to create releases with minimal configuration. Release Drafter is better suited for projects requiring detailed changelogs, while Action GH Release excels in simplicity and ease of use for basic release needs.
An action which manages a github release
Pros of release-action
- More customizable release options, including the ability to generate release notes automatically
- Supports uploading multiple assets in a single step
- Allows for updating existing releases, not just creating new ones
Cons of release-action
- Slightly more complex configuration due to additional features
- May require more setup time for simple release scenarios
- Less focused on GitHub-specific release features
Code Comparison
action-gh-release:
- uses: softprops/action-gh-release@v1
with:
files: |
dist/*.tar.gz
dist/*.zip
release-action:
- uses: ncipollo/release-action@v1
with:
artifacts: "dist/*.tar.gz,dist/*.zip"
generateReleaseNotes: true
updateOnlyUnreleased: true
Both actions serve the purpose of creating GitHub releases, but release-action offers more advanced features and customization options. While action-gh-release is simpler and more straightforward for basic release needs, release-action provides greater flexibility for complex release workflows. The choice between the two depends on the specific requirements of your project and the level of control you need over the release process.
Convert
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
action gh-release
A GitHub Action for creating GitHub Releases on Linux, Windows, and macOS virtual environments

𤸠Usage
ð¥ Limit releases to pushes to tags
Typically usage of this action involves adding a step to a build that
is gated pushes to git tags. You may find step.if
field helpful in accomplishing this
as it maximizes the reuse value of your workflow for non-tag pushes.
Below is a simple example of step.if
tag gating
name: Main
on: push
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Release
uses: softprops/action-gh-release@v2
if: github.ref_type == 'tag'
You can also use push config tag filter
name: Main
on:
push:
tags:
- "v*.*.*"
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Release
uses: softprops/action-gh-release@v2
â¬ï¸ Uploading release assets
You can configure a number of options for your GitHub release and all are optional.
A common case for GitHub releases is to upload your binary after its been validated and packaged.
Use the with.files
input to declare a newline-delimited list of glob expressions matching the files
you wish to upload to GitHub releases. If you'd like you can just list the files by name directly.
If a tag already has a GitHub release, the existing release will be updated with the release assets.
Below is an example of uploading a single asset named Release.txt
name: Main
on: push
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Build
run: echo ${{ github.sha }} > Release.txt
- name: Test
run: cat Release.txt
- name: Release
uses: softprops/action-gh-release@v2
if: github.ref_type == 'tag'
with:
files: Release.txt
Below is an example of uploading more than one asset with a GitHub release
name: Main
on: push
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Build
run: echo ${{ github.sha }} > Release.txt
- name: Test
run: cat Release.txt
- name: Release
uses: softprops/action-gh-release@v2
if: github.ref_type == 'tag'
with:
files: |
Release.txt
LICENSE
â ï¸ Note: Notice the
|
in the yaml syntax above âï¸. That lets you effectively declare a multi-line yaml string. You can learn more about multi-line yaml syntax here
â ï¸ Note for Windows: Paths must use
/
as a separator, not\
, as\
is used to escape characters with special meaning in the pattern; for example, instead of specifyingD:\Foo.txt
, you must specifyD:/Foo.txt
. If you're using PowerShell, you can do this with$Path = $Path -replace '\\','/'
ð External release notes
Many systems exist that can help generate release notes for you. This action supports loading release notes from a path in your repository's build to allow for the flexibility of using any changelog generator for your releases, including a human ð©âð»
name: Main
on: push
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Generate Changelog
run: echo "# Good things have arrived" > ${{ github.workspace }}-CHANGELOG.txt
- name: Release
uses: softprops/action-gh-release@v2
if: github.ref_type == 'tag'
with:
body_path: ${{ github.workspace }}-CHANGELOG.txt
repository: my_gh_org/my_gh_repo
# note you'll typically need to create a personal access token
# with permissions to create releases in the other repo
token: ${{ secrets.CUSTOM_GITHUB_TOKEN }}
ð Customizing
inputs
The following are optional as step.with
keys
Name | Type | Description |
---|---|---|
body | String | Text communicating notable changes in this release |
body_path | String | Path to load text communicating notable changes in this release |
draft | Boolean | Indicator of whether or not this release is a draft |
prerelease | Boolean | Indicator of whether or not is a prerelease |
preserve_order | Boolean | Indicator of whether order of files should be preserved when uploading assets |
files | String | Newline-delimited globs of paths to assets to upload for release |
overwrite_files | Boolean | Indicator of whether files should be overwritten when they already exist. Defaults to true |
name | String | Name of the release. defaults to tag name |
tag_name | String | Name of a tag. defaults to github.ref_name |
fail_on_unmatched_files | Boolean | Indicator of whether to fail if any of the files globs match nothing |
repository | String | Name of a target repository in <owner>/<repo> format. Defaults to GITHUB_REPOSITORY env variable |
target_commitish | String | Commitish value that determines where the Git tag is created from. Can be any branch or commit SHA. Defaults to repository default branch. |
token | String | Secret GitHub Personal Access Token. Defaults to ${{ github.token }} |
discussion_category_name | String | If specified, a discussion of the specified category is created and linked to the release. The value must be a category that already exists in the repository. For more information, see "Managing categories for discussions in your repository." |
generate_release_notes | Boolean | Whether to automatically generate the name and body for this release. If name is specified, the specified name will be used; otherwise, a name will be automatically generated. If body is specified, the body will be pre-pended to the automatically generated notes. See the GitHub docs for this feature for more information |
append_body | Boolean | Append to existing body instead of overwriting it |
make_latest | String | Specifies whether this release should be set as the latest release for the repository. Drafts and prereleases cannot be set as latest. Can be true , false , or legacy . Uses GitHub api defaults if not provided |
ð¡ When providing a body
and body_path
at the same time, body_path
will be
attempted first, then falling back on body
if the path can not be read from.
ð¡ When the release info keys (such as name
, body
, draft
, prerelease
, etc.)
are not explicitly set and there is already an existing release for the tag, the
release will retain its original info.
outputs
The following outputs can be accessed via ${{ steps.<step-id>.outputs }}
from this action
Name | Type | Description |
---|---|---|
url | String | Github.com URL for the release |
id | String | Release ID |
upload_url | String | URL for uploading assets to the release |
assets | String | JSON array containing information about each uploaded asset, in the format given here (minus the uploader field) |
As an example, you can use ${{ fromJSON(steps.<step-id>.outputs.assets)[0].browser_download_url }}
to get the download URL of the first asset.
environment variables
The following step.env
keys are allowed as a fallback but deprecated in favor of using inputs.
Name | Description |
---|---|
GITHUB_TOKEN | GITHUB_TOKEN as provided by secrets |
GITHUB_REPOSITORY | Name of a target repository in <owner>/<repo> format. defaults to the current repository |
â ï¸ Note: This action was previously implemented as a Docker container, limiting its use to GitHub Actions Linux virtual environments only. With recent releases, we now support cross platform usage. You'll need to remove the
docker://
prefix in these versions
Permissions
This Action requires the following permissions on the GitHub integration token:
permissions:
contents: write
When used with discussion_category_name
, additional permission is needed:
permissions:
contents: write
discussions: write
GitHub token permissions can be set for an individual job, workflow, or for Actions as a whole.
Note that if you intend to run workflows on the release event (on: { release: { types: [published] } }
), you need to use
a personal access token for this action, as the default secrets.GITHUB_TOKEN
does not trigger another workflow.
Doug Tangren (softprops) 2019
Top Related Projects
An Action to create releases via the GitHub Release API
Drafts your next release notes as pull requests are merged into master.
An action which manages a github release
Convert
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot