mikepenz/action-junit-report

Test report publishing step errors on 3.3.0

midgleyc opened this issue · 11 comments

midgleyc commented

The crash mostly appears in the logs after the "Publish results" step is skipped, but seems like it happens asynchronously (e.g. on https://github.com/kolmafia/kolmafia/runs/7930092463 it appears after "Retrieved 1 reports to process.").

HttpError: Resource not accessible by integration
    at /home/runner/work/_actions/mikepenz/action-junit-report/v3/webpack:/action-junit-report/node_modules/@octokit/request/dist-node/index.js:86:1
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

Here is a failing run: https://github.com/kolmafia/kolmafia/runs/7930011115

It worked on 3.3.0, at least some of the time: https://github.com/kolmafia/kolmafia/actions/runs/2885651235. It would sometimes not create the report on 3.2.0, but it wouldn't crash.

mikepenz commented

This looks to be pointing to a permission issue possibly: octokit/rest.js#37 ?

mikepenz commented

Given that the related octokit/rest ticket points towards a permission issue. Have you also checked this section regarding token scope: https://github.com/mikepenz/action-junit-report#pr-run-permissions ?

midgleyc commented

That explains the behaviour I see: I'm doing a PR from a fork, and the passing runs don't.

However, the behaviour was slightly different in 3.2.0: it would print an error (and not fail the check) instead of crashing as it does here.

Also, if job_summary is false and skipped, there shouldn't be anything it fails to do, right? Because the thing it fails to do is to create an extra summary on the test. However it still crashes.

midgleyc commented

Sorry, looks like I've misinterpreted what happens. I agree there's a permissions issue, but the behaviour is different compared with 3.2.0.

In 3.2.0, an error message "Failed to create checks using the provided token" is printed, but the step passes overall.

In 3.3.0, that error message is not printed, the stack trace appears, and the step is marked as a failure.

This implies that the error is not being caught?

mikepenz commented

Going by the assumption that the error log shows the actual call order the crash occurs.

If I interpret the error log correctly, the error is logged in the Process test results group, which happens before the action posts the job_summary.

The job_summary will only be posted in the Publish results group: https://github.com/mikepenz/action-junit-report/blob/main/src/main.ts#L98-L128

mikepenz commented

Yes that is surely strange. 🤔.

Both annotation calls are being wrapped in a try/catch to handle that: https://github.com/mikepenz/action-junit-report/blob/main/src/main.ts#L100-L117

Not sure why it would not catch it

midgleyc commented

Ah. annotateTestResult is asynchronous, but not awaited. I think that could do it.

attachSummary also is asynchronous.

mikepenz commented

@midgleyc 😮. You are absolutely right. I wished javascript would warn about that

midgleyc commented

I have used https://typescript-eslint.io/rules/no-floating-promises/. It's not exactly the right use-case, but it is the closest I've found.

midgleyc commented

Thanks for the prompt fix / discussion!

mikepenz commented

Appreciate working through this with you! and thanks for the link to the no-floating-promises