The runner has received a shutdown signal

[grische]

While running the action-gh-release action, we regularly encounter issues that the operation has been cancelled.
It failed after 17 minutes, so I assume it is not a timeout.

It seems to be happening after the last uploaded concluded.

Here is an example running with Debug enabled: https://github.com/freifunkMUC/site-ffm/actions/runs/4940203059/jobs/8842882643

Here are the last lines before it failed:

⬆️ Uploading x86-legacy_output.tar.gz...
##[debug]Re-evaluate condition on job cancellation for step: 'Create Release & Upload Release Assets'.
##[debug]Skip Re-evaluate condition on runner shutdown.
Error: The operation was canceled.
##[debug]System.OperationCanceledException: The operation was canceled.
##[debug]   at System.Threading.CancellationToken.ThrowOperationCanceledException()

Other (non-expired) examples are:

• https://github.com/freifunkMUC/site-ffm/actions/runs/4940203059/jobs/8836080422
• https://github.com/freifunkMUC/site-ffm/actions/runs/4335649576/jobs/7571678793
• https://github.com/freifunkMUC/site-ffm/actions/runs/4335649576/jobs/7571530699

[grische]

@softprops is there anything else we can provide to help debugging the issue?

[smallprogram]

like this ,workflow:

jobs:
  job_init: 
    runs-on: ubuntu-latest
    steps:
    - name: Generate Image
      id: generate_image
      run: |
        mkdir output
        cd $GITHUB_WORKSPACE/output
        dd if=/dev/zero of=outputfile.img.00 bs=1M count=1900
        dd if=/dev/zero of=outputfile.img.01 bs=1M count=1900
        dd if=/dev/zero of=outputfile.img.02 bs=1M count=1900
        dd if=/dev/zero of=outputfile.img.03 bs=1M count=1900
        dd if=/dev/zero of=outputfile.img.04 bs=1M count=1900
        dd if=/dev/zero of=outputfile.img.05 bs=1M count=1900
        echo "FIRMWARE=$PWD" >> $GITHUB_ENV
        echo "status=success" >> $GITHUB_OUTPUT
    - name: Upload Toolchain to release
      uses: softprops/action-gh-release@v0.1.15
      if: steps.generate_image.outputs.status == 'success'
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      with:
        tag_name: 'test'
        files: ${{ env.FIRMWARE }}/*    

return

The runner has received a shutdown signal. This can happen when the runner service is stopped, or a manually started runner is canceled.

[smallprogram]

Is there anyone who can help fix this issue? It bothers me so much

[grische]

@softprops is it possible to limit the number of files uploaded? If we send them one by one it might work properly.

[smallprogram]

@grische
I tried it and found that this problem occurs when the remaining storage space of /dev/root is less than the total size of the files to be uploaded. When the remaining storage space of /dev/root is larger than the total size of the files to be uploaded, there will be no problem. I don't know if it will be of any use to you.
I don’t know if this is a solution to the problem, but for now, it works for me

[seppzer0]

I encountered the same issue a few hours ago, while trying to release a few large files via this GitHub Action.
@softprops , any ideas for a workaround?

[seppzer0]

I confirmed that this issue is relevant to this particular GitHub action only.

I used a similar release action to publish the same amount of files with 4.9 Gb size in total. And it worked just fine.

In comparison, here is the same pipeline using your action.

[enumag]

I ran into the same issue. I believe it is because the runner ran out of memory because this tool loads all the files into memory before uploading them:

action-gh-release/src/github.ts

Line 131 in c9b46fe

data: readFileSync(path),

Well in my case it was 4 files, each around 1.5 GB so 6 GB total so no wonder it was too much.

It is of course a big mistake that this is happening. Upload (especially upload with potentially large files) should always be written in a way that doesn't load them into memory all at once but just one chunk at a time.

[enumag]

Did someone find an alternative tool that doesn't have this issue? There is a ton on GitHub Actions Marketplace but so far I couldn't find one that would be similarly feature complete and not have this bug.

[enumag]

@softprops It shouldn't be too difficult to fix this bug. Most likely you just need to use this: https://www.geeksforgeeks.org/node-js-fs-createreadstream-method/