Top Related Projects
📦 :octocat: GitHub Action for creating GitHub Releases
Drafts your next release notes as pull requests are merged into master.
An Action to create releases via the GitHub Release API
Quick Overview
ncipollo/release-action is a GitHub Action that automates the process of creating releases on GitHub. It allows users to easily create releases with customizable names, body text, and attached assets, streamlining the release management process for projects hosted on GitHub.
Pros
- Easy integration with GitHub Actions workflows
- Supports multiple file upload formats, including wildcards
- Customizable release names and body text, with support for markdown formatting
- Ability to create draft releases and pre-releases
Cons
- Limited to GitHub platform, not suitable for other version control systems
- Requires some familiarity with GitHub Actions and workflow syntax
- May require additional setup for complex release scenarios
- Limited control over release artifact organization compared to manual releases
Getting Started
To use the ncipollo/release-action in your GitHub Actions workflow, add the following step to your workflow file:
- name: Create Release
uses: ncipollo/release-action@v1
with:
artifacts: "dist/*"
bodyFile: "body.md"
token: ${{ secrets.GITHUB_TOKEN }}
This example creates a release with all files in the dist
directory as artifacts, uses the contents of body.md
as the release body, and authenticates using the default GitHub token.
To create a draft release with a custom name and tag:
- name: Create Draft Release
uses: ncipollo/release-action@v1
with:
artifacts: "build/app.apk,build/app.ipa"
draft: true
name: "v1.0.0 Beta"
tag: "v1.0.0-beta"
token: ${{ secrets.GITHUB_TOKEN }}
This example creates a draft release named "v1.0.0 Beta" with the tag "v1.0.0-beta" and includes two specific files as artifacts.
For more advanced usage and configuration options, refer to the project's README on GitHub.
Competitor Comparisons
📦 :octocat: GitHub Action for creating GitHub Releases
Pros of action-gh-release
- More actively maintained with frequent updates
- Supports custom release notes generation
- Offers more flexibility in asset uploading
Cons of action-gh-release
- Lacks built-in changelog generation
- Doesn't support automatic version bumping
- May require more configuration for complex release scenarios
Code Comparison
release-action:
- uses: ncipollo/release-action@v1
with:
artifacts: "release.tar.gz,foo/*.txt"
bodyFile: "body.md"
token: ${{ secrets.GITHUB_TOKEN }}
action-gh-release:
- uses: softprops/action-gh-release@v1
with:
files: |
release.tar.gz
foo/*.txt
body_path: body.md
token: ${{ secrets.GITHUB_TOKEN }}
Both actions provide similar functionality for creating GitHub releases, but they differ in their approach and feature set. release-action offers built-in changelog generation and automatic version bumping, which can be beneficial for projects with standardized release processes. On the other hand, action-gh-release provides more flexibility in asset uploading and custom release notes generation, making it suitable for projects with unique release requirements.
The code comparison shows that both actions have similar syntax for specifying artifacts/files and body content. However, action-gh-release uses a multi-line format for specifying files, which can be more readable for longer lists of assets.
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
- Supports customizable categorization of changes (e.g., features, bug fixes)
- Maintains a draft release that can be manually edited before publishing
Cons of Release Drafter
- Requires more setup and configuration to achieve desired results
- Limited to creating draft releases, cannot directly publish releases
- Less flexibility in terms of release asset management
Code Comparison
Release Drafter configuration:
template: |
## What's Changed
$CHANGES
categories:
- title: '🚀 Features'
labels:
- 'feature'
- title: '🐛 Bug Fixes'
labels:
- 'fix'
Release Action usage:
- uses: ncipollo/release-action@v1
with:
artifacts: "release.tar.gz,foo/*.txt"
bodyFile: "body.md"
token: ${{ secrets.GITHUB_TOKEN }}
Release Drafter focuses on generating release notes based on pull requests, while Release Action provides more direct control over release creation and asset uploading. Release Drafter is better suited for projects with frequent contributions and a need for automated changelog generation, whereas Release Action offers more flexibility for projects with specific release requirements and asset management needs.
An Action to create releases via the GitHub Release API
Pros of create-release
- Official GitHub action, potentially more stable and supported
- Simpler setup for basic release creation
- Integrates seamlessly with GitHub's release system
Cons of create-release
- Limited customization options
- Lacks advanced features like uploading multiple assets or updating existing releases
- No support for generating release notes from commit messages
Code Comparison
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
release-action:
- uses: ncipollo/release-action@v1
with:
artifacts: "release.tar.gz,foo/*.txt"
bodyFile: "body.md"
token: ${{ secrets.GITHUB_TOKEN }}
draft: true
prerelease: false
generateReleaseNotes: true
release-action offers more flexibility and features, such as uploading multiple artifacts, using a separate file for the release body, and automatically generating release notes. However, create-release may be preferred for simpler use cases or when official GitHub integration is a priority. The choice between the two depends on the specific requirements of your project and workflow.
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
Release Action
This action will create a GitHub release and optionally upload an artifact to it.
Action Inputs
Input name | Description | Required | Default Value |
---|---|---|---|
allowUpdates | An optional flag which indicates if we should update a release if it already exists. Defaults to false. | false | "" |
artifactErrorsFailBuild | An optional flag which indicates if artifact read or upload errors should fail the build. | false | "" |
artifacts | An optional set of paths representing artifacts to upload to the release. This may be a single path or a comma delimited list of paths (or globs) | false | "" |
artifactContentType | The content type of the artifact. Defaults to raw | false | "" |
body | An optional body for the release. Note: This input will have white space trimmed before and after it. Use bodyFile if you need a non-trivial markdown body. | false | "" |
bodyFile | An optional body file for the release. This should be the path to the file. | false | "" |
commit | An optional commit reference. This will be used to create the tag if it does not exist. | false | "" |
discussionCategory | When provided this will generate a discussion of the specified category. The category must exist otherwise this will cause the action to fail. This isn't used with draft releases. The default "Announcements" category is not supported via the API and will cause an error if used here. | false | "" |
draft | Optionally marks this release as a draft release. Set to true to enable. | false | "" |
generateReleaseNotes | Indicates if release notes should be automatically generated. | false | false |
makeLatest | Indicates if the release should be the "latest" release or not. legacy specifies that the latest release should be determined based on the release creation date and higher semantic version. | false | "legacy" |
name | An optional name for the release. If this is omitted the tag will be used. | false | "" |
omitBody | Indicates if the release body should be omitted. | false | false |
omitBodyDuringUpdate | Indicates if the release body should be omitted during updates. The body will still be applied for newly created releases. This will preserve the existing body during updates. | false | false |
omitDraftDuringUpdate | Indicates if the draft flag should be omitted during updates. The draft flag will still be applied for newly created releases. This will preserve the existing draft state during updates. | false | false |
omitName | Indicates if the release name should be omitted. | false | false |
omitNameDuringUpdate | Indicates if the release name should be omitted during updates. The name will still be applied for newly created releases. This will preserve the existing name during updates. | false | false |
omitPrereleaseDuringUpdate | Indicates if the prerelease flag should be omitted during updates. The prerelease flag will still be applied for newly created releases. This will preserve the existing prerelease state during updates. | false | false |
owner | Optionally specify the owner of the repo where the release should be generated. Defaults to current repo's owner. | false | "current repo owner" |
prerelease | Optionally marks this release as prerelease. Set to true to enable. | false | "" |
removeArtifacts | Indicates if existing release artifacts should be removed. | false | false |
replacesArtifacts | Indicates if existing release artifacts should be replaced. | false | true |
repo | Optionally specify the repo where the release should be generated. | false | current repo |
skipIfReleaseExists | When skipIfReleaseExists is enabled the action will be skipped if a non-draft release already exists for the provided tag. | false | false |
tag | An optional tag for the release. If this is omitted the git ref will be used (if it is a tag). | false | "" |
token | The GitHub token. This will default to the GitHub app token. This is primarily useful if you want to use your personal token (for targeting other repos, etc). If you are using a personal access token it should have access to the repo scope. | false | github.token |
updateOnlyUnreleased | When allowUpdates is enabled, this will fail the action if the release it is updating is not a draft or a prerelease. | false | false |
Action Outputs
Output name | Description |
---|---|
id | The identifier of the created release. |
html_url | The HTML URL of the release. |
upload_url | The URL for uploading assets to the release. |
tarball_url | The URL for downloading the release as a tarball (.tar.gz). |
zipball_url | The URL for downloading the release as a zipball (.zip). |
assets | JSON string containing a map of asset names to download URLs for uploaded assets. |
Example
This example will create a release when a tag is pushed:
name: Releases
on:
push:
tags:
- '*'
jobs:
build:
runs-on: ubuntu-latest
permissions:
contents: write
steps:
- uses: actions/checkout@v4
- uses: ncipollo/release-action@v1
with:
artifacts: "release.tar.gz,foo/*.txt"
bodyFile: "body.md"
Notes
- You must provide a tag either via the action input or the git ref (i.e push / create a tag). If you do not provide a tag the action will fail.
- If the tag of the release you are creating does not yet exist, you should set both the
tag
andcommit
action inputs.commit
can point to a commit hash or a branch name (ex -main
). - In the example above only required permissions for the action specified (which is
contents: write
). If you add other actions to the same workflow you should expandpermissions
block accordingly. - More info about why the default discussion category "Announcements" does not work with this action may be found here: https://github.com/goreleaser/goreleaser/issues/2304.
Top Related Projects
📦 :octocat: GitHub Action for creating GitHub Releases
Drafts your next release notes as pull requests are merged into master.
An Action to create releases via the GitHub Release API
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