v1.3.4

Includes all v1.3.4 improvements:

• Updated dependencies

Includes all v1.3.3 improvements:

• Updated octokit dependencies

Includes all v1.3.2 improvements:

• Updated to node16 and @actions/core 1.10 (patriziobruno)
• Thank you to our contributors:
  • patriziobruno

Includes all v1.3.1 bug fixes:

• Fixed bug that caused releases with more than 100 assets to not be updated correctly (beyarkay)
• Thank you to our contributors:
  • beyarkay

Includes all v1.3.0 changes:

• Validation of tag name choice
• Fixed issue with first time creating a release

Includes all v1.2.0 changes:

• Fixed tag auto-updating
• Added updateTag option to automatically update the tag to the latest commit (default value is true)

Includes all initial v1.1.0 changes in Isaac Shelton's fork of ColinPitrat/update-release which itself is a fork of johnwbyrd/update-release:

• Updated all dependencies to latest versions
• Code now works with latest version of GitHub API
• Added replace option, to allow for removing attached files that aren't overwritten
• Now works correctly when the release doesn't exist already (it will be added before updating)
• Cleaned up a little of the code, although it still isn't the cleanest

Example Usage:

    - name: Update release
      uses: IsaacShelton/[email protected]
      with:
        token: ${{ secrets.YOUR_PRIVATE_SECRET_TOKEN }}
        release: Nightly
        replace: true
        files: >
          stage/x86_64-Windows-HelloWorld.exe
          stage/arm64-MacOS-HelloWorld
          stage/x86_64-Ubuntu-HelloWorld

Guide

Once your build has successfully completed, update-existing-release will choose a release name for your build. Regardless of whether the ref that triggered the build is a tag or a branch, you'll get a human-friendly release name. You can override the default name if you wish. If the Github release name already exists, it is reused; otherwise, it is created.

Inputs

This action has the following inputs:

Input	Description
token (required)	This should be your secure Github token. Use ${{ secrets.GITHUB_TOKEN }} if your build lasts less than an hour. Otherwise, you will need to create your own access token with repo admin access, store it as a secret in your own repository, and reference that secret token in your build.
files (required)	The files that you want for your the release. Presumably, this should include at least one file that you just built. File paths can be provided as absolute paths, or they can be relative to ${{ github.workspace }}.
release	The name of the release to be created. If none is supplied, a reasonable looking one will be chosen based on ${{ github.ref }}.
tag	The name of the tag to be created. For some inexplicable reason, Github thinks that you need to have a tag corresponding to every release, which makes no sense if you're using Github to do continuous integration builds. The tag will be the same as the calculated name of the release, if this input is not supplied.
message	A brief description of the tag and also of the release.
body	A longer description of the release, if it is created.
prerelease	Whether to mark the release, if created, as a prerelease. Such releases are generally publicly visible. This is false by default.
draft	Whether to mark the release, if created, as a draft. Such releases are generally not publicly visible. This is false by default.
replace (since v1.1.0)	Whether to remove existing files of the release that are not overwritten. This will cause all existing files attached to the release to be removed and replaced with the files provided. This is false by default.
updateTag (since v1.2.0)	Whether to update the tag to the latest commit. If the tag doesn't already exist, it will be created pointing to the latest commit regardless of this option. This is true by default.

Outputs

If successful, this action will have the following outputs:

Output	Description
files	The calculated local paths of the files to be uploaded into the release
draft	Whether the release, if created, was marked as a draft
prerelease	Whether the release, if created, was marked as a prerelease
release	The name of the release
tag	The tag used to create the release

v1.3.3

Includes all v1.3.3 improvements:

• Updated octokit dependencies

Includes all v1.3.2 improvements:

• Updated to node16 and @actions/core 1.10 (patriziobruno)
• Thank you to our contributors:
  • patriziobruno

Includes all v1.3.1 bug fixes:

• Fixed bug that caused releases with more than 100 assets to not be updated correctly (beyarkay)
• Thank you to our contributors:
  • beyarkay

Includes all v1.3.0 changes:

• Validation of tag name choice
• Fixed issue with first time creating a release

Includes all v1.2.0 changes:

• Fixed tag auto-updating
• Added updateTag option to automatically update the tag to the latest commit (default value is true)

Includes all initial v1.1.0 changes in Isaac Shelton's fork of ColinPitrat/update-release which itself is a fork of johnwbyrd/update-release:

• Updated all dependencies to latest versions
• Code now works with latest version of GitHub API
• Added replace option, to allow for removing attached files that aren't overwritten
• Now works correctly when the release doesn't exist already (it will be added before updating)
• Cleaned up a little of the code, although it still isn't the cleanest

Example Usage:

    - name: Update release
      uses: IsaacShelton/[email protected]
      with:
        token: ${{ secrets.YOUR_PRIVATE_SECRET_TOKEN }}
        release: Nightly
        replace: true
        files: >
          stage/x86_64-Windows-HelloWorld.exe
          stage/arm64-MacOS-HelloWorld
          stage/x86_64-Ubuntu-HelloWorld

Guide

Once your build has successfully completed, update-existing-release will choose a release name for your build. Regardless of whether the ref that triggered the build is a tag or a branch, you'll get a human-friendly release name. You can override the default name if you wish. If the Github release name already exists, it is reused; otherwise, it is created.

Inputs

This action has the following inputs:

Input	Description
token (required)	This should be your secure Github token. Use ${{ secrets.GITHUB_TOKEN }} if your build lasts less than an hour. Otherwise, you will need to create your own access token with repo admin access, store it as a secret in your own repository, and reference that secret token in your build.
files (required)	The files that you want for your the release. Presumably, this should include at least one file that you just built. File paths can be provided as absolute paths, or they can be relative to ${{ github.workspace }}.
release	The name of the release to be created. If none is supplied, a reasonable looking one will be chosen based on ${{ github.ref }}.
tag	The name of the tag to be created. For some inexplicable reason, Github thinks that you need to have a tag corresponding to every release, which makes no sense if you're using Github to do continuous integration builds. The tag will be the same as the calculated name of the release, if this input is not supplied.
message	A brief description of the tag and also of the release.
body	A longer description of the release, if it is created.
prerelease	Whether to mark the release, if created, as a prerelease. Such releases are generally publicly visible. This is false by default.
draft	Whether to mark the release, if created, as a draft. Such releases are generally not publicly visible. This is false by default.
replace (since v1.1.0)	Whether to remove existing files of the release that are not overwritten. This will cause all existing files attached to the release to be removed and replaced with the files provided. This is false by default.
updateTag (since v1.2.0)	Whether to update the tag to the latest commit. If the tag doesn't already exist, it will be created pointing to the latest commit regardless of this option. This is true by default.

Outputs

If successful, this action will have the following outputs:

Output	Description
files	The calculated local paths of the files to be uploaded into the release
draft	Whether the release, if created, was marked as a draft
prerelease	Whether the release, if created, was marked as a prerelease
release	The name of the release
tag	The tag used to create the release

v1.3.2

Includes all v1.3.2 improvements:

• Updated to node16 and @actions/core 1.10 (patriziobruno)
• Thank you to our contributors:
  • patriziobruno

Includes all v1.3.1 bug fixes:

• Fixed bug that caused releases with more than 100 assets to not be updated correctly (beyarkay)
• Thank you to our contributors:
  • beyarkay

Includes all v1.3.0 changes:

• Validation of tag name choice
• Fixed issue with first time creating a release

Includes all v1.2.0 changes:

• Fixed tag auto-updating
• Added updateTag option to automatically update the tag to the latest commit (default value is true)

Includes all initial v1.1.0 changes in Isaac Shelton's fork of ColinPitrat/update-release which itself is a fork of johnwbyrd/update-release:

• Updated all dependencies to latest versions
• Code now works with latest version of GitHub API
• Added replace option, to allow for removing attached files that aren't overwritten
• Now works correctly when the release doesn't exist already (it will be added before updating)
• Cleaned up a little of the code, although it still isn't the cleanest

Example Usage:

    - name: Update release
      uses: IsaacShelton/[email protected]
      with:
        token: ${{ secrets.YOUR_PRIVATE_SECRET_TOKEN }}
        release: Nightly
        replace: true
        files: >
          stage/x86_64-Windows-HelloWorld.exe
          stage/arm64-MacOS-HelloWorld
          stage/x86_64-Ubuntu-HelloWorld

Guide

Once your build has successfully completed, update-existing-release will choose a release name for your build. Regardless of whether the ref that triggered the build is a tag or a branch, you'll get a human-friendly release name. You can override the default name if you wish. If the Github release name already exists, it is reused; otherwise, it is created.

Inputs

This action has the following inputs:

Input	Description
token (required)	This should be your secure Github token. Use ${{ secrets.GITHUB_TOKEN }} if your build lasts less than an hour. Otherwise, you will need to create your own access token with repo admin access, store it as a secret in your own repository, and reference that secret token in your build.
files (required)	The files that you want for your the release. Presumably, this should include at least one file that you just built. File paths can be provided as absolute paths, or they can be relative to ${{ github.workspace }}.
release	The name of the release to be created. If none is supplied, a reasonable looking one will be chosen based on ${{ github.ref }}.
tag	The name of the tag to be created. For some inexplicable reason, Github thinks that you need to have a tag corresponding to every release, which makes no sense if you're using Github to do continuous integration builds. The tag will be the same as the calculated name of the release, if this input is not supplied.
message	A brief description of the tag and also of the release.
body	A longer description of the release, if it is created.
prerelease	Whether to mark the release, if created, as a prerelease. Such releases are generally publicly visible. This is false by default.
draft	Whether to mark the release, if created, as a draft. Such releases are generally not publicly visible. This is false by default.
replace (since v1.1.0)	Whether to remove existing files of the release that are not overwritten. This will cause all existing files attached to the release to be removed and replaced with the files provided. This is false by default.
updateTag (since v1.2.0)	Whether to update the tag to the latest commit. If the tag doesn't already exist, it will be created pointing to the latest commit regardless of this option. This is true by default.

Outputs

If successful, this action will have the following outputs:

Output	Description
files	The calculated local paths of the files to be uploaded into the release
draft	Whether the release, if created, was marked as a draft
prerelease	Whether the release, if created, was marked as a prerelease
release	The name of the release
tag	The tag used to create the release

v1.3.1

Includes all v1.3.1 bug fixes:

• Fixed bug that caused releases with more than 100 assets to not be updated correctly
• Thank you to our contributors:
  • beyarkay

Includes all v1.3.0 changes:

• Validation of tag name choice
• Fixed issue with first time creating a release

Includes all v1.2.0 changes:

• Fixed tag auto-updating
• Added updateTag option to automatically update the tag to the latest commit (default value is true)

Includes all initial v1.1.0 changes in Isaac Shelton's fork of ColinPitrat/update-release which itself is a fork of johnwbyrd/update-release:

• Updated all dependencies to latest versions
• Code now works with latest version of GitHub API
• Added replace option, to allow for removing attached files that aren't overwritten
• Now works correctly when the release doesn't exist already (it will be added before updating)
• Cleaned up a little of the code, although it still isn't the cleanest

Example Usage:

    - name: Update release
      uses: IsaacShelton/[email protected]
      with:
        token: ${{ secrets.YOUR_PRIVATE_SECRET_TOKEN }}
        release: Nightly
        replace: true
        files: >
          stage/x86_64-Windows-HelloWorld.exe
          stage/arm64-MacOS-HelloWorld
          stage/x86_64-Ubuntu-HelloWorld

Guide

Once your build has successfully completed, update-existing-release will choose a release
name for your build. Regardless of whether the ref that triggered the build is
a tag or a branch, you'll get a human-friendly release name. You can of course
override the default choice. If the Github release name already exists, it is
reused; otherwise, it is created.

Inputs

The following parameters are accepted as inputs to the update-existing-release action.

token

This should be your secure Github token.
Use ${{ secrets.GITHUB_TOKEN }} as the parameter if your build lasts less than an hour.

If your build lasts more than an hour, you will need to create your own access token
with repo admin access, store it as a secret
in your own repository, and reference that secret token in your build.

This parameter is required.

files

The paths to files that you wish to add to the release.
Presumably, this should include at least one file that you just built.
File paths can be provided as absolute paths, or they can alternately be
relative to ${{ github.workspace }}.

This parameter is required.

release

The name of the release to be created. A reasonable-looking release name will
be created from the current ${{ github.ref }} if this input is not supplied.
This reasonable looking default is created by taking ${{ github.ref }},
removing the prefixes refs/, heads/, and tags/ , and then replacing any
remaining forward-slash symbols / with dashes -.

If you don't like this behavior, just override the release name here yourself.

This parameter is optional.

tag

The name of the tag to be created. For some inexplicable reason, Github thinks
that you need to have a tag corresponding to every release, which makes no
sense if you're using Github to do continuous integration builds. The tag will
be the same as the calculated name of the release, if this input is not
supplied.

This parameter is optional.

message

A brief description of the tag and also of the release.

This parameter is optional.

body

A longer description of the release, if it is created.

This parameter is optional.

prerelease

Should the release, if created, be marked as a prerelease?
Such releases are generally publicly visible.
Provide true or false as a parameter.

This parameter is optional.
The default setting is false.

draft

Should the release, if created, be marked as a draft? Such releases are
generally not publicly visible. Provide true or false as a parameter.

This parameter is optional.
The default setting is false.

replace (since v1.1.0)

Added in Isaac Shelton's fork.

Should existing files for the release be removed if not overwritten?
This will cause all existing files attached to the release to be
removed and replaced with the files provided.

This parameter is optional.
The default setting is false.

updateTag (since v1.2.0)

Added in Isaac Shelton's fork.

Should the tag be updated to point to the latest commit?

If set, the provided tag will be modified.

If the tag doesn't already exist (regardless of updateTag), it will be created pointing to the latest commit.

This parameter is optional.
The default setting is true.

Outputs

If assets are successfully published, you will get the following outputs from
the step, which you can use in later processing.

The following parameters are provided as outputs to this Github action.

files

The calculated local paths of the files to be uploaded into the release.

draft

Whether the release, if created, was marked as a draft.

prerelease

Whether the release, if created, was marked as a prerelease.

release

The name of the release.

tag

The tag used to create the release.

Internals

Setup

To build under Debian (should be easy to adapt):

apt-get install webpack npm
npm install --save-dev typescript ts-loader v8-compile-cache
npm run bundle

v1.3.0

Includes all v1.3.0 changes in Isaac Shelton's fork:

• Validation of tag name choice
• Fixed issue with first time creating a release

Includes all v1.2.0 changes in Isaac Shelton's fork:

• Fixed tag auto-updating
• Added updateTag option to automatically update the tag to the latest commit (default value is true)

Includes all initial v1.1.0 changes in Isaac Shelton's fork of ColinPitrat/update-release which itself is a fork of johnwbyrd/update-release:

• Updated all dependencies to latest versions
• Code now works with latest version of GitHub API
• Added replace option, to allow for removing attached files that aren't overwritten
• Now works correctly when the release doesn't exist already (it will be added before updating)
• Cleaned up a little of the code, although it still isn't the cleanest

Example Usage:

    - name: Update release
      uses: IsaacShelton/[email protected]
      with:
        token: ${{ secrets.YOUR_PRIVATE_SECRET_TOKEN }}
        release: Nightly
        replace: true
        files: >
          stage/x86_64-Windows-HelloWorld.exe
          stage/arm64-MacOS-HelloWorld
          stage/x86_64-Ubuntu-HelloWorld

Guide

Once your build has successfully completed, update-existing-release will choose a release
name for your build. Regardless of whether the ref that triggered the build is
a tag or a branch, you'll get a human-friendly release name. You can of course
override the default choice. If the Github release name already exists, it is
reused; otherwise, it is created.

Inputs

The following parameters are accepted as inputs to the update-existing-release action.

token

This should be your secure Github token.
Use ${{ secrets.GITHUB_TOKEN }} as the parameter if your build lasts less than an hour.

If your build lasts more than an hour, you will need to create your own access token
with repo admin access, store it as a secret
in your own repository, and reference that secret token in your build.

This parameter is required.

files

The paths to files that you wish to add to the release.
Presumably, this should include at least one file that you just built.
File paths can be provided as absolute paths, or they can alternately be
relative to ${{ github.workspace }}.

This parameter is required.

release

The name of the release to be created. A reasonable-looking release name will
be created from the current ${{ github.ref }} if this input is not supplied.
This reasonable looking default is created by taking ${{ github.ref }},
removing the prefixes refs/, heads/, and tags/ , and then replacing any
remaining forward-slash symbols / with dashes -.

If you don't like this behavior, just override the release name here yourself.

This parameter is optional.

tag

The name of the tag to be created. For some inexplicable reason, Github thinks
that you need to have a tag corresponding to every release, which makes no
sense if you're using Github to do continuous integration builds. The tag will
be the same as the calculated name of the release, if this input is not
supplied.

This parameter is optional.

message

A brief description of the tag and also of the release.

This parameter is optional.

body

A longer description of the release, if it is created.

This parameter is optional.

prerelease

Should the release, if created, be marked as a prerelease?
Such releases are generally publicly visible.
Provide true or false as a parameter.

This parameter is optional.
The default setting is false.

draft

Should the release, if created, be marked as a draft? Such releases are
generally not publicly visible. Provide true or false as a parameter.

This parameter is optional.
The default setting is false.

replace (since v1.1.0)

Added in Isaac Shelton's fork.

Should existing files for the release be removed if not overwritten?
This will cause all existing files attached to the release to be
removed and replaced with the files provided.

This parameter is optional.
The default setting is false.

updateTag (since v1.2.0)

Added in Isaac Shelton's fork.

Should the tag be updated to point to the latest commit?

If set, the provided tag will be modified.

If the tag doesn't already exist (regardless of updateTag), it will be created pointing to the latest commit.

This parameter is optional.
The default setting is true.

Outputs

If assets are successfully published, you will get the following outputs from
the step, which you can use in later processing.

The following parameters are provided as outputs to this Github action.

files

The calculated local paths of the files to be uploaded into the release.

draft

Whether the release, if created, was marked as a draft.

prerelease

Whether the release, if created, was marked as a prerelease.

release

The name of the release.

tag

The tag used to create the release.

Internals

Setup

To build under Debian (should be easy to adapt):

apt-get install webpack npm
npm install --save-dev typescript ts-loader v8-compile-cache
npm run bundle

v1.2.0 - Update Existing Releases on GitHub

Includes all v1.2.0 changes in Isaac Shelton's fork:

• Fixed tag auto-updating
• Added updateTag option to automatically update the tag to the latest commit (default value is true)

Includes all initial v1.1.0 changes in Isaac Shelton's fork of ColinPitrat/update-release which itself is a fork of johnwbyrd/update-release:

• Updated all dependencies to latest versions
• Code now works with latest version of GitHub API
• Added replace option, to allow for removing attached files that aren't overwritten
• Now works correctly when the release doesn't exist already (it will be added before updating)
• Cleaned up a little of the code, although it still isn't the cleanest

Example Usage:

    - name: Update release
      uses: IsaacShelton/[email protected]
      with:
        token: ${{ secrets.YOUR_PRIVATE_SECRET_TOKEN }}
        release: Nightly
        replace: true
        files: >
          stage/x86_64-Windows-HelloWorld.exe
          stage/arm64-MacOS-HelloWorld
          stage/x86_64-Ubuntu-HelloWorld

Guide

Once your build has successfully completed, update-existing-release will choose a release
name for your build. Regardless of whether the ref that triggered the build is
a tag or a branch, you'll get a human-friendly release name. You can of course
override the default choice. If the Github release name already exists, it is
reused; otherwise, it is created.

Inputs

The following parameters are accepted as inputs to the update-existing-release action.

token

This should be your secure Github token.
Use ${{ secrets.GITHUB_TOKEN }} as the parameter if your build lasts less than an hour.

If your build lasts more than an hour, you will need to create your own access token
with repo admin access, store it as a secret
in your own repository, and reference that secret token in your build.

This parameter is required.

files

The paths to files that you wish to add to the release.
Presumably, this should include at least one file that you just built.
File paths can be provided as absolute paths, or they can alternately be
relative to ${{ github.workspace }}.

This parameter is required.

release

The name of the release to be created. A reasonable-looking release name will
be created from the current ${{ github.ref }} if this input is not supplied.
This reasonable looking default is created by taking ${{ github.ref }},
removing the prefixes refs/, heads/, and tags/ , and then replacing any
remaining forward-slash symbols / with dashes -.

If you don't like this behavior, just override the release name here yourself.

This parameter is optional.

tag

The name of the tag to be created. For some inexplicable reason, Github thinks
that you need to have a tag corresponding to every release, which makes no
sense if you're using Github to do continuous integration builds. The tag will
be the same as the calculated name of the release, if this input is not
supplied.

This parameter is optional.

message

A brief description of the tag and also of the release.

This parameter is optional.

body

A longer description of the release, if it is created.

This parameter is optional.

prerelease

Should the release, if created, be marked as a prerelease?
Such releases are generally publicly visible.
Provide true or false as a parameter.

This parameter is optional.
The default setting is false.

draft

Should the release, if created, be marked as a draft? Such releases are
generally not publicly visible. Provide true or false as a parameter.

This parameter is optional.
The default setting is false.

replace (since v1.1.0)

Added in Isaac Shelton's fork.

Should existing files for the release be removed if not overwritten?
This will cause all existing files attached to the release to be
removed and replaced with the files provided.

This parameter is optional.
The default setting is false.

updateTag (since v1.2.0)

Added in Isaac Shelton's fork.

Should the tag be updated to point to the latest commit?

If set, the provided tag will be modified.

If the tag doesn't already exist (regardless of updateTag), it will be created pointing to the latest commit.

This parameter is optional.
The default setting is true.

Outputs

If assets are successfully published, you will get the following outputs from
the step, which you can use in later processing.

The following parameters are provided as outputs to this Github action.

files

The calculated local paths of the files to be uploaded into the release.

draft

Whether the release, if created, was marked as a draft.

prerelease

Whether the release, if created, was marked as a prerelease.

release

The name of the release.

tag

The tag used to create the release.

Internals

Setup

To build under Debian (should be easy to adapt):

apt-get install webpack npm
npm install --save-dev typescript ts-loader v8-compile-cache
npm run bundle