Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork940
Have CodeQL scan GitHub Actions workflows as well as Python code#2032
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
So GitHub can regenerate a fresh new one based on current defaults.
This adds CodeQL scanning of GitHub Actions, while continuing toscan Python as well.This will subsequently be customized slightly to restore someelements of the preivous custom workflow that we may prefer.
This restores three aspects of the previous `codeql.yml`:- Run it on all branches, not just `main`.- Run it on the previous schedule rather than the new one, since there's no reason to change the schedule (though there's no reason to be attached to the old schedule either).- Use "CodeQL" rather than "CodeQL Advanced" as the workflow `name`, since this takes up less horizontal space when reading the reports from the checks.Of these, only the first is really significant.
This is another change back to the way we had it before, but theremovals are based specifically on the guidance in the defaultworkflow comments about why each permission was given by default.
This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear onthis overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check outthe documentation. |
EliahKagan commentedMay 30, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
I guess this comment was automatically posted because the approach I took was to delete the workflow in the first commit to let GitHub regenerate it. (Or maybe this comment is posted for all changes to the workflow now?) |
2e4a0d2 intogitpython-developers:mainUh oh!
There was an error while loading.Please reload this page.
Three CI workflows that need only `contents: read` permissions andno other permissions did not have explicit permissions set, andwould therefore be given permissions configured for the repository.It is recommended to set explicit workflow permissions. This doesso, bringing those workflows inline with `pythonpackage.yml` (whichhad this), and closing three `actions/missing-workflow-permissions`CodeQL alerts (new sincegitpython-developers#2032 enabled scanning of GHA workflows).See also:https://codeql.github.com/codeql-query-help/actions/actions-missing-workflow-permissions/
Three CI workflows that need only `contents: read` permissions andno other permissions did not have explicit permissions set, andwould therefore be given default permissions configured for therepository, which might be more expansive than the workflows need.It is recommended to set explicit workflow permissions [1]. Thisdoes that, specifying permissions as `pythonpackage.yml` alreadydid, and closing three `actions/missing-workflow-permissions`CodeQL alerts (new sincegitpython-developers#2032 enabled scanning of GHA workflows).[1]:https://codeql.github.com/codeql-query-help/actions/actions-missing-workflow-permissions/
Uh oh!
There was an error while loading.Please reload this page.
This regenerates the
codeq.ymlworkflow to modernize it and to get current defaults, the most (or perhaps only) important one being to scan bothpythonandactions, rather than onlypython.Parts of the default that we deliberately deviate from, or that seem preferable to change based on the comments in the default workflow, are put back.
I've tested this in my fork, but I'll still wait for all CI to complete here before merging. Besides being a good usual practice, this also has a chance of catching permissions-related problems.