-
Notifications
You must be signed in to change notification settings - Fork 4
feat(zizmor): run zizmor against actions and workflows #20
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
Conversation
.github/workflows/self-zizmor.yaml
Outdated
| uses: grafana/shared-workflows/.github/workflows/reusable-zizmor.yml@5946b80e86f32bb4d208c2483c58345bbeef03d2 | ||
| with: | ||
| codeql-enabled: false |
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.
Let's get
- feat(zizmor): use a default config file shared-workflows#946
- fix(zizmor): try code scanning by default shared-workflows#947
merged, so we use an org-wide default configuration, and then
| uses: grafana/shared-workflows/.github/workflows/reusable-zizmor.yml@5946b80e86f32bb4d208c2483c58345bbeef03d2 | |
| with: | |
| codeql-enabled: false | |
| uses: grafana/shared-workflows/.github/workflows/reusable-zizmor.yml@8fa210559ab2cc62e7b12d3bb9cba19dbc862c11 |
to use that, and upload the results where we can.
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.
OK we're there 👍 I updated the suggestion with the SHA
| security-events: write | ||
|
|
||
| uses: grafana/shared-workflows/.github/workflows/reusable-zizmor.yml@5946b80e86f32bb4d208c2483c58345bbeef03d2 | ||
| with: |
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.
Just to confirm, this will go straight to blocking - is that the intention?
To do "informational only", it'd be
| with: | |
| with: | |
| fail-severity: never |
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.
The intention is that it'd be a failing test, but not "required" if there's anything that's high or above (which I think is the default). So it shouldn't immediately block, and then the "required" one would block on failure once we turn that one on
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.
Ok - just as a note of caution: I've rolled out changes like that before, and I'd say that the notion of a required check is not super well understood. We ended up getting quite a few questions from folks asking how they could unblock their stuff, when it never was blocked, because they'd seen the ❌.
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.
Ahh I see, yeah, I think in this case we probably kinda want that behaviour, no technical block, but prompting folks to update their workflows with the suggestion.
|
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. |
Create a workflow to run zizmor against this repository and others in Grafana