The repo on which this action is running is not opted-in to CodeQL code scanning.

[wsugarman]

Hi,

Our repository microsoft/dicom-server has code scanning alerts enabled with a CodeQL job that looks over both our C# and Javascript code. However, occasionally our CI and PR CodeQL actions will fail with the error: "The repo on which this action is running is not opted-in to CodeQL code scanning."

This is clearly not the case, as it succeeds most of the time. Is something misconfigured on our end, or is there an issue with the CodeQL action?

Example: https://github.com/microsoft/dicom-server/actions/runs/636934044

[hvitved]

Hi @wsugarman

Apologize for the inconvenience. This might be related to https://www.githubstatus.com/incidents/d24w1hd9cc8x; could you please let us know if this happens again?

Thanks

[fsouza]

Hey there, I'm experiencing this two, in multiple repos. Examples:

• https://github.com/fsouza/fake-gcs-server/runs/2076667730
• https://github.com/fsouza/s3-upload-proxy/runs/2076667702

[fsouza]

Oh, just merged another PR and it's building fine now! 🎉

[wsugarman]

Thanks @hvitved

I haven't seen the issue again so far. If I don't see it today, I'll close the issue and continue to monitor.

Thanks again!

[jeswr]

I experienced the same issues across several of my repositories two days ago, and again ~1hr ago.

I re-ran the action a few minutes ago and it appears to be working okay again.

[robertbrignull]

Nothing much to add but I've opened an issue internally so this will get investigated at some point. If the same workflow is working sometimes and not working other times on the same repository, then it seems like an intermittent internal bug or race condition.

[wsugarman]

Thanks! I am also continuing to see this issue intermittently

[KnicKnic]

@robertbrignull is it known if more repros are needed? Any eta? Our latest hit - https://github.com/microsoft/dicom-server/runs/2124256428

[robertbrignull]

@KnicKnic, thanks for the link. We're looking into it now. Shouldn't need any more explicit links as we should be able to find them from our side.

[aeisenberg]

In #424 we changed the error messages so that the errors are more explicit.

[robertbrignull]

Worth noting that the above change won't stop the error happening, so don't be alarmed if it still does. It's just the error message will not be incorrect anymore. We're still working on the lower level fix.

[ebozduman]

Is there any workaround to this issue?
I also see it and the error is the same.
Error: The repo on which this action is running is not opted-in to CodeQL code scanning.

[Hazmi35]

This happens for me a while ago, now it's showing RequestError [HttpError]: Resource not accessible by integration with a status of 403

[robertbrignull]

The change in error message is expected and it's now showing a more correct error. The repository is still enrolled in code scanning, but there's another bug that has happened.

What's actually going on here is that workflows run on branches or pull requests made by dependabot only receive a token with read access by default. This is causing code scanning workflows to fail because they require the security_events: write scope. There currently also appears to a bug where these reduced scopes get applied even after the commit is merged to the default branch.

We are working to find an easy and secure way around this so that code scanning works by default when used alongside dependabot.

In the meantime it appears if you retry one of these failed analyses then the new workflow run will be given write access so it will succeed. So if you do need the results from that analysis you can retry the workflow run and it should succeed then.

[robertbrignull]

We have now worked out precisely what the problem is and what can be done about it. Unfortunately we can't easily or safely make the existing workflows work, however there are simple workarounds that'll let you still get code scanning results in all cases.

What is the problem

A recent change to dependabot means that workflows triggered by dependabot run with read-only permissions as if they were run from a fork. Unfortunately this has impacted code scanning workflows that run on push because uploading code scanning results requires write access.

Code scanning workflows that run on the pull_request event are not affected because of an existing features which gives the token provided by actions the ability to upload code scanning results for that pull request and only that pull request. We can't currently and don't plan to do a similarly targeted exception for dependabot pushes, and giving it the ability to upload code scanning results for any ref would be insecure.

Unfortunately pretty much the only thing we can do is to change the error message to be more clear what's going on. In #435 the error message will change to explain the problem and link to some documentation. That change will go live next week. Unfortunately an error message like that is not enough space to explain it fully, so we will also publish a more detailed explanation in the documentation and link to that once it's available.

Only use the pull_request event for dependabot PRs

The good news is that it's easy to work around the above restrictions. Instead of running code scanning on pushes to every branch, you'll be able to get the same code scanning coverage by only running on pushes to a smaller set of branches (e.g. main, develop, release branches, ...) and then also running on the pull_request event for PRs targeting these branches.

See https://docs.github.com/en/code-security/secure-coding/configuring-code-scanning#scanning-on-push for how we recommend setting up code scanning and see https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestbranchestags for more info on the branches/branches-ignore syntax. The default workflow has changed over time so if you set up code scanning a while ago your workflow may be different from what's in those docs.

The simplest set of workflow triggers which will still likely work for a majority of projects might look like:

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

An alternative approach that runs on all pushes except dependabot would be:

on:
  push:
    branches-ignore:
      - 'dependabot/**'
  pull_request:

Analysis still failing on the default branch

You may still run into cases where code scanning fails on commits made by dependabot even once the commit has been merged into the default branch. Quite a few of the examples earlier in this issue are this case. The reason for this is that in some cases the commit that gets merged into the default branch is solely authored by dependabot and thus the workflow runs with read-only permissions.

From what we can tell the only case where this can happen is if the dependabot PR is merged by using the @dependabot squash and merge syntax. Our advice would be to avoid using this syntax if at all possible. Thankfully the new feature to automatically merge a pull request may be able to help here and fulfil the same functionality.

Retrying analysis

Another thing to note is that performing certain actions on a workflow run changes its state from having dependabot as the actor that triggered the workflow to being you triggering the workflow. This includes things like merging main into the PR, or retrying the workflow run. When the workflow run retries it'll run with write permissions and code scanning will succeed.

Be aware that you may be running untrusted code, so check what change dependabot has made to avoid security breaches from compromised dependencies. If you are happy though then retrying the failed workflow run should make it succeed.

[robertbrignull]

I'm going to tentatively close this issue as we've done as much of a fix as we can for now and the above comment explains the context and workarounds.

[melink14]

(Maybe leave this open until documentation is updated? it took awhile to find this since the error message points to documentation that doesn't mention this problem or how to fix it while still using dependabot. The error message is especially missing details wrt to @dependabot merge command causing failures (which later causes comparitive analysis to fail for normal PRs))

[nihaals]

I think pinning this issue would make more sense

[robertbrignull]

Some official docs on this issue are now available at https://docs.github.com/en/code-security/secure-coding/automatically-scanning-your-code-for-vulnerabilities-and-errors/troubleshooting-the-codeql-workflow#error-403-resource-not-accessible-by-integration-when-using-dependabot
There's no new information there that isn't in #416 (comment), but good to note that the docs are updated now.