Failure due to Error: Resource not accessible by integration

[pattacini]

As per the title:

Here's the relevant snippet: https://github.com/robotology/icub-main/blob/master/.github/workflows/ci.yml#L35-L37.

Just posting a snapshot too as I'm very likely going to patch it.

[pattacini]

I forgot to say that the failure happens for pull requests generated by forks.
And the reason for that is probably explained here: https://github.com/styfle/cancel-workflow-action#advanced-pull-requests-from-forks.

[pattacini]

Replacing the standard GITHUB_TOKEN with a proper secret with repo and workflows scope didn't help.

[olekspickle]

I reproduced it with my toy repo, honestly I hoped it would just work :)

[pattacini]

Thanks for testing @alekspickle 👍🏻
Keep me posted if you find a way to get around this inconvenience!

[pattacini]

Just for your information, there's no way that a workflow triggered by a pull_request generated by a public fork can have access to the repo secrets for having the necessary write permissions to cancel a job.

What I did was to trigger a workflow_run type CI to cancel the caller.

Here's an example: https://github.com/robotology/icub-main/blob/master/.github/workflows/cancel-ci-draft-pr.yml.

[sigprof]

This particular case may be solved even without cancelling the workflow — a condition like this added to the build job should work:

    if: >-
      !( (github.event_name == 'pull_request') && github.event.pull_request.draft )

The real problem is when the workflow actually has multiple jobs (not just a single job with a matrix), there is some parallelism in the job dependencies (so multiple different jobs can be running at the same time), and you want to cancel the whole workflow immediately when one of those jobs fails:

• The strategy.fail-fast option does not work in this case (it can cancel only other instances of the same job, but does nothing for other jobs that might be running).
• The workflow does not have the permissions to cancel itself if it was triggered by a pull_request from a fork (GITHUB_TOKEN is restricted, and there is no access to secrets to provide another token).
• There is no event that gets triggered on a job failure, so you cannot even start another workflow which would have the permissions to cancel the broken workflow run. Even though a failed job should show up as a failed check for the commit, the check_run event is not triggered when the check was performed by GitHub Actions (apparently only third-party checks can trigger it).

[pattacini]

Hi @sigprof

I know that one can use the if condition but I thought that ( (github.event_name == 'pull_request') && github.event.pull_request.draft ) can be somehow problematic as the pull_request payload checked by the second logic operation may be only available for events of type pull_request, actually. The if might be also cut short because of the and condition, so the result of the first operation may be sufficient when it is false, but I don't think it's a good pattern anyhow.

I didn't check honestly if it could have worked out and I explored some more articulated options with the idea that I wanted to make the job show up eventually as canceled in the action dashboard instead of being marked as failed.

Long story short, I learned a lot and came up with a solution based on the workflow_run event, which basically allows us to queue workflows and thus address point 2 and point 3 of your list.

Check out https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run for more details, especially for what regards the possibility to run a workflow based on the conclusion of another workflow.

[andymckay]

Glad you found a workaround for your case 👍🏾

[TamimiGitHub]

I'm still getting the Resource not accessible by integration error when attempting to cancel the workflow. This action is triggered on merge, so has nothing to do with PRs.

Wondering if this issue persists to someone else?

[albinahlback]

Yeah, I get this when using certain actions (in my case ilammy/msvc-dev-cmd).

[mxcl]

upgrading to 0.3 fixed this for me.

If this action had a v0 tag I wouldn't have even seen this bug. Just saying.

[ivankovnatsky]

On 0.3 version, had to add:

permissions:
  actions: write

[paulz]

when we tried to permission, job fails to checkout:

  Error: fatal: repository 'https://github.com/.../' not found
  Error: The process '.../git' failed with exit code 128

when adding:

   permissions:
      actions: write 

at the job level