-
Notifications
You must be signed in to change notification settings - Fork 106
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add codeql analysis workflow for JS #981
Conversation
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
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 on this 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 out the documentation. |
b5ff7a6
to
f2e3482
Compare
Co-authored-by: Weston Ruter <westonruter@google.com>
526f1ed
to
a085b32
Compare
@joemcgill @felixarntz can you folks please take a look? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @thelovekesh. I've left a couple of comments, but don't see any blockers.
@@ -2,7 +2,7 @@ | |||
/admin @mukeshpanchal27 @felixarntz | |||
/tests/admin @mukeshpanchal27 @felixarntz | |||
/bin @mukeshpanchal27 @felixarntz | |||
/.github @mukeshpanchal27 @felixarntz | |||
/.github @mukeshpanchal27 @felixarntz @thelovekesh |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not opposed, but am wondering if we should specify code owners specifically for workflows, rather than the whole directory?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@joemcgill Not sure what would be more appropriate but I am okay to review any workflow file changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this would be more appropriate as I will be working on optimizing most of the workflows under #973
# Cancel previous workflow run groups that have not completed. | ||
concurrency: | ||
# Group workflow runs by workflow name, along with the head branch ref of the pull request | ||
# or otherwise the branch or tag ref. | ||
group: ${{ github.workflow }}-${{ github.event_name == 'pull_request' && github.head_ref || github.ref }} | ||
cancel-in-progress: true | ||
|
||
# Disable permissions for all available scopes. | ||
# Enable permissions for specific scopes as needed on job level. | ||
permissions: {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm assuming these are copied from the props-bot workflow? Seems sensible to me, just noting that most of our workflows don't include concurrency groups or a removal of permissions scopes. I assume the concurrency group here is meant to cancel any in-progress jobs on PRs whenever a new commit is pushed to that branch or if the current workflow is restarted for some reason?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@joemcgill Most of the workflows rely on a third-party action to control the concurrency which is okay but I am not in favor of depending on third-party dependencies while something can be achieved natively, and yes it's here for cancelling the previous workflow run.
Also restricting the permission in the runner is a good practice to keep the metadata of a repo intact in case some action is compromised.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@thelovekesh Your rationale makes sense to me, however I would be in favor of making such decisions consistently. I think for this PR we should stick with how we have been handling concurrency and permissions so far, as changing that is not the purpose of the PR. And then we can open a separate issue and/or PR to consider changing it holistically.
There is no good reason why this workflow should behave differently from the other ones in those points.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@felixarntz TBH, I'm not sure if we should be prevented from writing optimized workflows by default just because existing workflows don't include those optimizations. In any case, as part of #973, I will be updating them.
name: Analyze | ||
runs-on: ubuntu-latest | ||
permissions: | ||
security-events: write |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since CodeQL requires permission to write to security events as per https://github.com/github/codeql-action?tab=readme-ov-file#permissions
More info on how it's add to security events - https://github.com/WordPress/performance/security/code-scanning?query=pr%3A981+is%3Aopen
push: | ||
# Only run if JS files changed. | ||
paths: | ||
- '**.js' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does CodeQL only cover first-party JS? What about dependencies? Just curious, I'm not familiar with CodeQL.
I'm only asking since, if it also covers dependencies, we may also want to include package.json
and package-lock.json
here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@felixarntz For dependencies, @dependabot creates security alerts that can be configured from - https://github.com/WordPress/performance/security/dependabot
# Cancel previous workflow run groups that have not completed. | ||
concurrency: | ||
# Group workflow runs by workflow name, along with the head branch ref of the pull request | ||
# or otherwise the branch or tag ref. | ||
group: ${{ github.workflow }}-${{ github.event_name == 'pull_request' && github.head_ref || github.ref }} | ||
cancel-in-progress: true | ||
|
||
# Disable permissions for all available scopes. | ||
# Enable permissions for specific scopes as needed on job level. | ||
permissions: {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@thelovekesh Your rationale makes sense to me, however I would be in favor of making such decisions consistently. I think for this PR we should stick with how we have been handling concurrency and permissions so far, as changing that is not the purpose of the PR. And then we can open a separate issue and/or PR to consider changing it holistically.
There is no good reason why this workflow should behave differently from the other ones in those points.
Summary
Add CodeQL analysis for JS language.
Fixes task 6 of #973
Relevant technical choices
security:write
permissions in workflow.Checklist
[Focus]
orInfrastructure
label.[Type]
label.no milestone
label.