upload asset after release creation on github.com

[staabm]

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]

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]

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

[staabm]

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]

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]

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 iit-danieli-joint-lab/idjl-software-dependencies-vcpkg#10 .

[asbjornu]

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.