Convert Figma logo to code with AI

ncipollo logorelease-action

An action which manages a github release

1,559
218
1,559
2

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 Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Release Action

This action will create a GitHub release and optionally upload an artifact to it.

Action Inputs

Input nameDescriptionRequiredDefault Value
allowUpdatesAn optional flag which indicates if we should update a release if it already exists. Defaults to false.false""
artifactErrorsFailBuildAn optional flag which indicates if artifact read or upload errors should fail the build.false""
artifactsAn 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""
artifactContentTypeThe content type of the artifact. Defaults to rawfalse""
bodyAn 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""
bodyFileAn optional body file for the release. This should be the path to the file.false""
commitAn optional commit reference. This will be used to create the tag if it does not exist.false""
discussionCategoryWhen 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""
draftOptionally marks this release as a draft release. Set to true to enable.false""
generateReleaseNotesIndicates if release notes should be automatically generated.falsefalse
makeLatestIndicates 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"
nameAn optional name for the release. If this is omitted the tag will be used.false""
omitBodyIndicates if the release body should be omitted.falsefalse
omitBodyDuringUpdateIndicates 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.falsefalse
omitDraftDuringUpdateIndicates 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.falsefalse
omitNameIndicates if the release name should be omitted.falsefalse
omitNameDuringUpdateIndicates 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.falsefalse
omitPrereleaseDuringUpdateIndicates 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.falsefalse
ownerOptionally specify the owner of the repo where the release should be generated. Defaults to current repo's owner.false"current repo owner"
prereleaseOptionally marks this release as prerelease. Set to true to enable.false""
removeArtifactsIndicates if existing release artifacts should be removed.falsefalse
replacesArtifactsIndicates if existing release artifacts should be replaced.falsetrue
repoOptionally specify the repo where the release should be generated.falsecurrent repo
skipIfReleaseExistsWhen skipIfReleaseExists is enabled the action will be skipped if a non-draft release already exists for the provided tag.falsefalse
tagAn optional tag for the release. If this is omitted the git ref will be used (if it is a tag).false""
tokenThe 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.falsegithub.token
updateOnlyUnreleasedWhen allowUpdates is enabled, this will fail the action if the release it is updating is not a draft or a prerelease.falsefalse

Action Outputs

Output nameDescription
idThe identifier of the created release.
html_urlThe HTML URL of the release.
upload_urlThe URL for uploading assets to the release.
tarball_urlThe URL for downloading the release as a tarball (.tar.gz).
zipball_urlThe URL for downloading the release as a zipball (.zip).
assetsJSON 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 and commit 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 expand permissions 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.