Conversation
- [`persist-credentials: false`](https://docs.zizmor.sh/audits/#artipacked) - [pinning `uses`](https://docs.zizmor.sh/audits/#unpinned-uses) I've focused only on our custom CI configuration, not on the CI configuration from upstream: I'm not even sure whether we run the upstream configuration, and even if we do, I'd prefer not to introduce changes (fairly invasive ones in some cases!) that might lead to merge conflicts. Ideally we'd do better someday, including trying to make changes upstream.
It looks like we "Prepare" but do nothing else: Now presumably it would be nice to pin actions for that step and perhaps make other changes. Or we could delete that configuration entirely (at the cost of having to tell Git to ignore changes to those deleted files when we see merge conflicts). |
| JAVA_VERSION: 24 | ||
| steps: | ||
| - uses: actions/checkout@v4 | ||
| - uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 |
There was a problem hiding this comment.
I think zizmor can add a comment for what version the SHA corresponds to?
Also, do we want to switch to a more recent version of this action while we're at it?
There was a problem hiding this comment.
Yes, thanks. (Or at least it will check that comments are correct, and Dependabot will (normally :)) update the comment when it updates the hash.) It looks like I can fill in a commit from a release along with a bogus version comment, and zizmor will correct the version comment. Done.
| persist-credentials: false | ||
| - name: Set up JDK 24 | ||
| uses: actions/setup-java@v4 | ||
| uses: actions/setup-java@c1e323688fd81a25caa38c78aa6df2d33d3e20d9 |
There was a problem hiding this comment.
Done.
I will also see about setting up Dependabot. I think we'd avoided it because it could introduce diffs for the JDK CI jobs discussed above, but it looks like we can provide Dependabot with a list of files to ignore (though sadly we can't enumerate the files to check AFAICT).
This would have saved us some effort in #149.
And that seems to take all of ~12 seconds: 
But that was apparently enough for me to get us into trouble by merging several commits in rapid succession, leading (I assume) the CI job for one to cancel previous jobs: 
Those then get reported as failures: 
I wondered if maybe the JDK CI was using jdk/.github/workflows/main.yml Lines 49 to 51 in bed19bc ...that differs from the one I've been moving projects to. I wonder if upstream would have any interest in a switch. |
2 participants
persist-credentials: falseusesI've focused only on our custom CI configuration, not on the CI configuration from upstream: I'm not even sure whether we run the upstream configuration, and even if we do, I'd prefer not to introduce changes (fairly invasive ones in some cases!) that might lead to merge conflicts. Ideally we'd do better someday, including trying to make changes upstream.