search

actions / upload-release-asset

An Action to upload a release asset via the GitHub Release API
MIT License
683 stars 187 forks source link

upload asset after release creation on github.com #34

Open staabm opened 4 years ago

staabm commented 4 years ago

I would like to upload a asset into a just created release.

the release will be created via the github.com website, and I would like to attach files to the just created release.

is this a supported workflow? how should/can it look like?

traversaro commented 4 years ago

I had the same question, investigating a bit on other repos, it seems possible in a GitHub Action triggered by a release event, but passing as upload_url: ${{ github.event.release.upload_url }}, see for an example https://github.com/chacon000/userinputweathergame/blob/7c82cac9dbdaaf5295a8726ff4c95878e1fefbc0/.github/workflows/makecode-release.yml#L36 . However, I still need to test this.

staabm commented 4 years ago

AFAIR we have a working worflow with https://github.com/staabm/annotate-pull-request-from-checkstyle/blob/master/.github/workflows/continuous-deployment.yml

staabm commented 4 years ago

Is that gonna help us via creating release thru web-ui and just then attach file to this release (we can do it manually thru edit button)?

not sure what you mean. the above linked action adds/attaches files to a relase which we create manueally via github.com UI (so we can't forget to add them).

traversaro commented 4 years ago

AFAIR we have a working worflow with https://github.com/staabm/annotate-pull-request-from-checkstyle/blob/master/.github/workflows/continuous-deployment.yml

Thanks a lot. I tried a bit, and indeed this seems to be working fine only if it is active only on published release event. Otherwise, I have failure problems, possibly related due concurring requests and related race conditions.

traversaro commented 4 years ago

AFAIR we have a working worflow with https://github.com/staabm/annotate-pull-request-from-checkstyle/blob/master/.github/workflows/continuous-deployment.yml

Thanks a lot. I tried a bit, and indeed this seems to be working fine only if it is active only on published release event. Otherwise, I have failure problems, possibly related due concurring requests and related race conditions.

Actually it turns out that at least part of this problem were due to the fact that we were using the GITHUB_TOKEN to upload the archives, but as our jobs is quite long, the job is longer then 1 hour, and so the GITHUB_TOKEN automatically generated expires. Use an explicitly generated access token fixed our problems, see https://github.com/iit-danieli-joint-lab/idjl-software-dependencies-vcpkg/pull/10 .

asbjornu commented 4 years ago

The suggestion to use on: release: types: published won't work for builds that are currently based on on: tags, where the artifacts to upload are being produced by a long series of build steps, tests, etc. to ensure that the uploaded artifacts are valid.

Having to rework builds to take on: release: types: published into account as an alternative to on: tags is a major head-ache.