release-0.9.1

release-0.9.1

The previous release, 0.9, attempted to improve the handling of errors by returning a "failure" result if the use of the Github API to perform the upload action did not return a HTTP 200/OK response. Unfortunately this was too strict.

This point-release updates the handling of uploads to test the HTTP status-code, and only mark the upload as a failure if the code is >=400. This means that HTTP 200/201/etc will be regarded as successful, and we don't have to worry quite so much about the specific value that is returned - which might change over time.

Once again this change was contributed & implemented by @varshavaradarajan, in #9.

release-0.9

release-0.9

This release updates our error-handling to recard a non-200 HTTP status-code as a failure.

The change builds upon #7, and was implemented by @varshavaradarajan in #8.

release-0.8

This release makes some minor improvements to the handling of our output messages:

• Any useful/interesting output is wrapped in stars (****) to make it more apparent in the github actions UI.
• The action invokes curl to add files to the release via the Github API
  • We now pretty-print the result from the API-calls, via jq.

The only other significant change is that we abort with a non-zero exit code if the curl-call fails.

However I suspect this won't be comprehensive, because the curl command could complete and regard itself as successful even if the remote API returns "out of disk-space", "artifact already present", or some other error-condition. We're solely relying upon the exit-code that curl returns here.

release-0.7

This release deprecates the use of the .github/build script. In the past this action did two things:

• Generated the project-specific artifacts by executing .github/build.
• Uploaded those artifacts, as specified by a glob-pattern.

It was noted in #3 that dual-functionality was a mixing of concerns, and in an ideal world the user would use distinct steps that they defined in their workflow to :

• Checkout the code.
• Run the build.
• Run some tests.
• Do more stuff.
• Then upload.

In short this action should only upload artifacts, so now the action has been converted to primarily upload artifacts as the name of the action suggests. There is legacy-support for continuing to run the .github/build script - if it is present, and if artifacts don't exist - but it is assumed you'll upgrade your workflow.

To peform a build and upload in a clean fashion this is a template which uses a distinct build-step, and a distinct upload-step:

on: release
name: Handle Release
jobs:
  generate:
    name: Create release-artifacts
    runs-on: ubuntu-latest
    steps:
      - name: Checkout the repository
        uses: actions/checkout@master
      - name: Generate artifacts
        uses: skx/github-action-build@master
      - name: Upload artifacts
        uses: skx/github-action-publish-binaries@master
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          args: 'example-*'

release-0.6

This release contains zero functional changes, instead it updates the documentation to refer to the new YAML-based setup that the Github Actions system uses - rather than the previous HCL-base configuration.

This was implemented via #1.

release-0.5

This release is being made solely to update the icon; the save icon is more descriptive than the previous choice.

release-0.4

This is the first working release:

• Uploads multiple binaries.
  • Which have been created by the .github/build script.