Skip to content

Releases: skx/github-action-publish-binaries

release-2.0

25 Sep 04:35
@skx skx
b9ca564
Compare
Choose a tag to compare

release-2.0

This release updates the docker image we generate to be smaller, and based upon the current stable release of Debian GNU/Linux, code-named "bullseye".

Both changes were contributed, with thanks, by @tklauser.

release-0.15

05 Jan 15:21
@skx skx
c881a3f
Compare
Choose a tag to compare

release-0.15

This release contains no functional changes, but updates the docker image which contains the action, to reduce its size.

Previously our container was built upon a golang-base, but now it is based upon a Debian GNU/Linux image, which is about 1/4th the size.

The suggestion was made in #27, and implemented in #28.

release-0.14

14 May 05:31
@skx skx
Compare
Choose a tag to compare

release-0.14

This release of the github-action-publish-binaries action allows you to specify the ID of the release to which the assets should be uploaded. By default we expect that this action will be invoked when a release is created, via a workflow file that starts like so:

on:
  release:
      types: [created]
name: Handle Release
jobs:
    ...

When the action is invoked with a newly created release we can extract the appropriate ID using jq, however it is possible that you might wish to chain actions, such that a preceeding action will create a release, and in that case you'll want to specify the release ID when invoking this action. That is now possible.

  • Reported in #20
  • Implemented in #21
    • Thanks to @09wattry for his patience and assistance.

release-1.3

07 Nov 19:19
@skx skx
9f2ea56
Compare
Choose a tag to compare

release-1.3

This release removes the restriction which was previously in place, which meant this action did nothing upon a draft-release event. Removing that restriction allows users to choose which events they wish this action to apply-to, and closes #15.

Currently the following release actions are supported:

  • published
  • unpublished
  • created
  • edited
  • deleted
  • prereleased

You will probably wish to consult the github actions documentation to make sure you're using the correct event:

release-1.2

28 Oct 18:32
@skx skx
Compare
Choose a tag to compare

release-1.2

This minor update explicitly passes the upload-pattern to the upload-script, to make the action more self-documenting.

release-1.1

28 Oct 18:02
@skx skx
60d124a
Compare
Choose a tag to compare

release-1.1

This release drops the legacy support for a project build-script, it now only uploads artifacts that exist when the release is made.

You should update your workflow to ensure that your artifacts are generated before they are uploaded, perhaps using my github-action-build action.

This was implemented in #14.

As the compatibility was changed I've bumped the release-tag to 1.x.

release-0.13

26 Oct 19:28
@skx skx
Compare
Choose a tag to compare

release-0.13

This release updates our action.yml file to correctly describe the environment within which it runs, by adding a top-level runs: key.

release-0.12

24 Oct 06:54
@skx skx
Compare
Choose a tag to compare

release-0.12

This release is being made solely to update the github action marketplace listing.

release-0.11

24 Oct 06:22
@skx skx
Compare
Choose a tag to compare

release-0.11

This is another documentation-only update. This action is designed to upload artifacts/binaries to a github release. By default when a release is created several events fire, which has the net result that the action runs multiple times. (Running multiple times is mostly harmless; the first one to run to completion will be fine. Subsequent runs will fail due to "Artifact already present")

I've updated the sample workflow included in the README to change the usage from this:

on: release

To this:

on:
release:
types: [created]

This ensures the action is only invoked once, when the release is created. Thanks to @Jeff-Tian for reporting this and giving a good example I was able to test.

release-0.10

23 Oct 07:05
@skx skx
Compare
Choose a tag to compare

release-0.10

This release updates the README file to explicitly note that you are not required to perform any manual setup with the GITHUB_TOKEN secret.

It is possible to add secrets to your project, via the project-settings, and refer to those in your Github Actions workflow-files. However the GITHUB_TOKEN value is handled transparently by the action-runner. If you attempt to define your own secret with that name you'll break the pipeline - so don't do that!