codeql/upload-sarif@v3 action failed: Resource not accessible by integration - missing actions: read
#2117
Comments
|
Thanks for posting. We're taking a look at this. Can you let us know the org/name of the repository where this is happening so we can look for this in our telemetry? |
aeisenberg
added
bug
|
@aeisenberg You can see at |
|
It looks like your workflow is failing at the point it is trying to send telemetry back to github.com, which is why we are not able to find any error reports in our logs about this. On Friday, we merged #2112 (and has already been released), which may fix an instance of this problem, but I'm not sure if this is exactly what you are seeing. Would you try again to see if this addresses your problem? If not, there is another PR that is more likely to address your issue: #2110. We are in the process of reviewing it. Once this PR is merged to main, I would recommend that you try this fix out as well. (Just change the |
|
@aeisenberg I've just tried with I'll wait and try when #2110 gets merged. |
This is a private repository (which I haven't mentioned) - so maybe that is the reason telemetry is not there? |
Thanks for trying.
We collect metadata (repository name, runtime, run status, etc) and error messages about all code scanning runs even in private repositories. This is to help us measure our internal SLOs and quickly see if there is a problem or any worrying trend. The data is purged after 6 months. |
|
@aeisenberg just checked after merging of #2110 with |
|
@SPodjasek The remaining changes in #2110 were just documentation. The functional change seems to be #2121 now. |
|
Ok, I'll monitor #2121 now... |
Oh. I bet I know what the problem ischeck-spelling has code for it:
Check Spelling: .github/workflows/spelling.yml#L106 Odds are that your repository is not a GHES or similar or that if you're a GHES or similar you aren't also paying for GitHub Advanced Security. check-spelling has to bend over backwards to handle this stuff (which is part of why I'm working on these repositories to make my experience slightly less tortured). retroactive edit: My bet was wrong, although in a way it was along the right track -- as it turns out it was a permissions issue, just not |
|
@jsoref Well, we do have GitHub Advanced Security license and it's enabled on the repository that throws errors. |
|
I've done some additional tests and whether Advanced Security is enabled or disabled on repository level we have the same error message:
There's also CodeQL workflow in that repository that runs code scanning on every push and it uploads results without any problem:
|
|
Interesting... I don't suppose you could set up an empty repository (private, with advanced security) with https://github.com/check-spelling/spell-check-this/blob/main/.github/workflows/spelling.yml and see what it says? |
|
In general workflow fails (
|
|
I've tried to downgrade Is it possible that the file itself is broken in some way and upload fails because of that? I'll try to store it in artifacts.... |
|
Here's the contents of SARIF file produced by Docker Scout: {
"version": "2.1.0",
"$schema": "https://json.schemastore.org/sarif-2.1.0.json",
"runs": [
{
"tool": {
"driver": {
"fullName": "Docker Scout",
"informationUri": "https://docker.com/products/docker-scout",
"name": "docker scout",
"rules": [],
"version": "1.4.1-SNAPSHOT-8f8fca4"
}
},
"results": []
}
]
} |
|
The main difference between v2 and v3 is just the runtime (runs.using: node16 vs runs.using: node20) -- it isn't an API break in the normal sense. I was wrong, the changes I'm working on should fix this... I've generated a number of bad json files, and generally that doesn't result in the error you're seeing. There should be a way to get all the headers (both sent and received) from the codeql action when it fails to post to the endpoint (I can't remember if there actually is, and in fact, I think it's missing, in which case we should add it). With those headers ... things become quite clear... |
|
So, some of the code paths are nice and will spit out a thing like:
The request id is (in theory) really helpful for doing things. I think the failure in my example above is more or less tied to this code path: codeql-action/src/init-action-post.ts Line 89 in 1515e2b which I think eventually led to this really valuable line: codeql-action/src/status-report.ts Line 332 in 1515e2b Now we just need to figure out which path you went down... |
|
For comparison, https://github.com/check-spelling-sandbox/decidim/actions/runs/7837152919/artifacts/1231830536 (currently) has an artifact tied to https://github.com/check-spelling-sandbox/decidim/actions/runs/7837152919#summary-21386271295 (which generated 238 sarif items). -- You're free to download the artifact and compare. Offhand, the lack of check-spelling's tool.driver doesn't have fullName, but otherwise there's nothing exciting in the json. |
|
Found the cause of this problem, missing permission: permissions:
actions: readwhich caused action to fail probably here (before any real upload occurs): codeql-action/src/upload-sarif-action.ts Lines 53 to 64 in 1515e2b |
|
Oh! Then, um, maybe the fix I'm working on would fix it. Definitely try |
|
I've forked this action repository to add some logging to see what's really going on, but I've noticed that it never reached real upload code. After disabling code mentioned above I got After adding this permission on job level it started to work. We do use reusable workflow which has permissions:
actions: writepermission declared in calling workflow, but job level declaration in called workflow was missing. |
|
Ok, we definitely want to add some code to ensure that that header is reported when things fail. I've filed: Which should improve life for the next person (once lots of things upgrade). Conveniently, triage for that project is on Fridays, so hopefully they'll look at it tomorrow. |
|
Fwiw, I won't be able to fully debug this edge case -- it requires having a GHES w/ GHAS and setting up a private repository. w/ public repositories, I did look through the code, but I can't precisely figure out where it's going off to try to talk to an actions endpoint (if I saw the url or had a stack trace of sorts, I might be able to figure things out). Could you update the description here to add "missing |
SPodjasek
changed the title
actions: read
|
Ok, with a bit of debugging, I can reproduce and it makes sense (check-spelling indeed does similar acrobatics) Here's the culprit: codeql-action/src/api-client.ts Lines 128 to 135 in 1515e2b |
|
In fact, check-spelling has fallback code where it rummages through the active repository trying to guess the answer in the case where it can't get the answer via the API: check-spelling/check-spelling@72af927 Pretty much every action author ends up reinventing some poor version of one of these various code things. It looks like this problem was fixed as of GHES 3.9 with the introduction of (Sadly there's still a 3.8 out there, but at least for most folks that's less of a problem.) |
|
With the fix to the above issue, the output I get for this case (private repository, no
Which is a huge improvement. (In order to get that, octokit would need to accept the PR, make a release, and then this repository would need to upgrade.) |
|
@SPodjasek: thanks for the help ... I think I now have two PRs to this repository that should be able to address the problem you've identified (plus the longer term debugging improvement to octokit). If you can comment on the open PRs indicating that they help this, that'd be helpful -- my testing involves creating a private repository and running a workflow w/ this action w/o |
|
@jsoref Just tested with your fork and after removing Should I keep this issue open until all PRs get merged for reference? |
|
Yes. I'd rather it be open to catch anyone else looking for it until it's fixed. |
|
Still catching up, but seems like |
TL;DR
When you'r facing this issue in private repository please add
to your workflow, or wait until this PR gets merged:
Fixed in
GITHUB_WORKFLOW_REFover usingactions: readto calculate the workflow path #2126When trying to upload sarif file produced by Docker Scout we get:
Resource not accessible by integration- despite thatsecurity-eventspermission is set towrite.Detailed workflow run logs are below. I've stripped output from scout as I believe it's irrelevant.
Logs
The text was updated successfully, but these errors were encountered: