I found a core file in the project folder, and gdb reported:

Core was generated by `/__e/node16/bin/node /__w/_actions/ncipollo/release-action/v1/dist/index.js'.
Program terminated with signal SIGABRT, Aborted.
#0  0xb6bed306 in ?? ()

So it looks like node ran out of memory while running the Action.

I took a look at the code, and in Artifacts.ts I noticed:

    readFile(): Buffer {
        return readFileSync(this.path)
    }

This might be acceptable for small files and runners with lots of memory, but it would be safer to use a stream.

The readFile method on Artifact now returns a ReadStream. It does look like octokit supports this as an argument type for the body: https://github.com/octokit/request.js/blob/main/test/request.test.ts#L906. I verified in my test repos that artifacts still upload with the stream.

Now whether or not they actually handle the stream correctly internally is another question ;)

Thank you for the quick fix, I appreciate it.

Tomorrow I'll probably have another such large artifact to upload, and I'll confirm if it was successful.

BTW, do you know if the self-hosted runner will download the new version of your action or will cache and re-use the same version that crashed before? Since the GitHub runner is active continuously, the machine runs non-stop. Probably you should have increased the version in package.json.

Have you seen any documentation about that version being relevant? I was under the impression actions just utilized tags, branches and commits.

Not actually sure how actions would be cached on a runner. I would assume they would see that the tag points to a new commit and pull it down, if not clone the action every run (but I don't really know for sure).

Have you seen any documentation about that version being relevant?

Unfortunately not... I extrapolated from my experience with the modules used by npm, which I also use in xpm. But the runner is open source, perhaps this detail can be understood from the code.

The build will take 10 more hours and tomorrow we'll know if it worked...

The large build from yesterday (550 MB) was the first build based on gcc 13.2.

This night build was an update based on gcc 12.3, and, being older, was slightly smaller, only 452 MB, so I can not fully confirm, but let's assume that the problem was solved. We'll know better when 13.3 will be out.

Thank you!