Resource not accessible by integration

[BrainStone]

I added the action to a workflow of mine. It works as expected for normal branches.

But for Pull Requests it fails with the error message:

Resource not accessible by integration

Example: https://github.com/AuraDevelopmentTeam/BungeeChat2/pull/178/checks?check_run_id=1586305366

[mikepenz]

Thank you @BrainStone for the report.

it seems this happened after it sent the success. would it be possible to run those with the debug flag?

https://docs.github.com/en/free-pro-team@latest/actions/managing-workflow-runs/enabling-debug-logging#enabling-step-debug-logging

If that's not ok to enable on that repo, may you be able to create a sample repo showcasing the issue so it's easier to debug. thank you so much

[BrainStone]

Does that look better?
https://github.com/AuraDevelopmentTeam/BungeeChat2/pull/178/checks?check_run_id=1591042531

[BrainStone]

Ah nevermind. My secrets don't propagate to a PR.

I'll see what I can do.

[BrainStone]

Alright. I hope that's right now: https://github.com/AuraDevelopmentTeam/BungeeChat2/pull/179/checks?check_run_id=1591140566

If not I believe it's fairly easy to reproduce with PRs.

[mikepenz]

I believe it may again be the token not being allowed to post on that repo?

[BrainStone]

Might be. The question is what is the solution?

[BrainStone]

Note you can give pull request permission to upload these artifacts. At least that's what I think that setting means in the actions settings.

[BrainStone]

Yet another case of actions/first-interaction#10

Utterly ridiculous that you can't even attach simple reports.

[JarLob]

The correct way is to use two workflows - pull_request and workflow_run as explained in https://securitylab.github.com/research/github-actions-preventing-pwn-requests

[mikepenz]

@BrainStone ultimately I see this to be a huge limitation still from the side of GitHub actions.

I'd say usually we would love builds to also execute for PRs from external people, but as those people may adjust the workflow which would allow them to log out your credentials or send them to some server, GitHub chose to block this all-together. E.g. don't allow non contributors to not get the creds for runs executed.

This isn't much better in enterprise accounts for non open source projects sadly.

I think ultimately we can hope that GitHub will introduce something like a "in-between solution". E.g. allow builds to be run for PRs but only if the builds were not modified. Or perhaps even better, use the builds from the current default branch from the main repo and ignore whatever there may be changed in the PR from possibly non trustworthy externals.

Alternative may also just be to block builds if anything within .github is modified in a PR from externals.

All these are great solutions, but sadly nothing we can solve as part of this action I am afraid.

[BrainStone]

It can be fixed easily: actions/first-interaction#10 (comment)

[mikepenz]

Oh that's amazing. Honestly I was not aware of it's existence.

Wonder why this is not communicated better by the docs

[JarLob]

Before you realize the pull_request_target doesn't checkout the pull request files by default and fix it to explicitly checkout head.ref I suggest you reading https://securitylab.github.com/research/github-actions-preventing-pwn-requests

[mikepenz]

Oh well that article makes this whole topic less amazing, with all the potential security risks. @JarLob thanks for adding it here.

to sum it up, the action itself can't do much about it. other than possibly not failing in case it is not allowed to write? but that could lead to errors being "suppressed" which is not really good either.

so finding the best way to write the action is the most important piece.

[JarLob]

The action itself is fine. Not sure if there is a way to check if the GH token is read-only. Maybe it is possible to catch the error and log more meaningful message. It all depends on a workflow use case. If you want to be more robust you can provide two examples in the readme.md. The existing one is fine for PRs from the same repo. The other one could show how to use pull_request with workflow_run to pass the test artifacts in a case of PR from a fork.

[mikepenz]

@BrainStone in case you haven't changed it yet. may you be able to re-run it which would fail. added a more meaningful error message for this case