Support release asset patching behavior to overwrite existing release assets

Hello, I’ve just discovered that the overwrite of already existing release assets of a existing release tag/name is not handled properly. The GitHub action just fails silent with not handled promise rejection warnings (why not errors?) and returns a success state, which is incorrect and should be failing!

The problem occurs in one of my nightly build and release GitHub workflows, which updates the same release tag/name with rebuild binaries, but the binaries are not updated at all. The following log message depicts the not handled promise rejection warning:

(node:2698) UnhandledPromiseRejectionWarning: HttpError: Validation Failed:
{"resource":"ReleaseAsset","code":"already_exists","field":"name"}
  at /home/runner/work/_actions/softprops/action-gh-release/v1/dist/index.js:1:273881
  at processTicksAndRejections (internal/process/task_queues.js:93:5)
(node:2698) UnhandledPromiseRejectionWarning: Unhandled promise rejection. 
This error originated either by throwing inside of an async function without a 
catch block, or by rejecting a promise which was not handled with .catch(). 
(rejection id: 1)

The issue and feature request is similar to #42, which describes a merging of assets, but not explicit overwrite. Maybe an option (e.g. asset) can be introduced in the GitHub action configuration to set different GitHub release patch behaviors.

• asset: create represents the current and default behavior, but shall fail if the asset already exists
• asset: patch represents a new behavior to overwrite only existing assets
• asset: merge represents a new behavior to overwrite existing and add new ones as well, so a combination of create and patch, which shall cover the issue in #42 as well.

A workflow example configuration would look like:

    - name: Release
      uses: softprops/action-gh-release@v1
      with:
        files: "artifacts/**"
        asset: patch
        tag_name: nightly
        name: nightly
        draft: false
        prerelease: true
        body: |
          Nightly release
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

[ppaulweber]

@proddy yes, I use another action to erase the existing release and then create a new one, but I would rather like to “re-release” to the same tag as proposed in this issue.

[proddy]

I just ran into this as well.

I used delete-tag-and-release as in https://github.com/proddy/EMS-ESP/blob/dev/.github/workflows/build_firmware.yml

sloppy, but it kinda works