Also a small pass on workflow names.
Note, I'm a little concerned that the test/nightly release/pre-commit
endpoints may be fragile. At the same time, it's also where it may be
most useful, to prevent network access by arbitrary test code. I think
this is imperfect, but maybe we can try it out and see if it's much of
an issue.
Note, the discord wiki action is currently broken, this should fix it.
This is coming out of advice from
https://securityscorecards.dev/viewer/?uri=github.com/carbon-language/carbon-lang
Updates action versions and pins by checksum. This is something we
already do in other places, and doing it with actions just seems
consistent.
Trying to add token permissions at the same time.
step-security/harden-runner is being set up to monitor network traffic
for actions, with the idea that we'd set it to block unexpected traffic
in the future.
Note, https://app.stepsecurity.io/secureworkflow generates the pinned
checksums and adds the harden-runner. In some cases it added token
permissions, but we have a couple it doesn't recognize (`gh` executions,
other custom commands, jlumbroso/free-disk-space, reviewdog/action-setup
as examples) so I'm trying to guess my best.
Because these are workflows, testing is limited.
Due to my workflow, I prefer to run `pre-commit` locally when I forget
to after an amend. While reviewdog can be helpful in the UI, it's mostly
making me mark comments as resolved as part of re-pushing. Rather than
continuing with this, maybe opting out is best?
This can't be done directly from a `pull_request` action, because that's
run without write privileges. This is done for security reasons, because
it runs in the context of the pull request branch. So instead, we
perform this in two steps:
- The `pull_request` action runs `pre-commit` and uploads an artifact
containing the diffs and the event information (which is only used to
extract the pull request number).
- A separate `workflow_run` action is triggered when the `pre-commit`
action finishes. This action is privileged, and should be able to
download the artifact and create corresponding suggestions.
Unfortunately, due to the permissions model in play here, the second
half of this appears to only be testable live in production.
For now, we're splitting the pre-commit action into two actions -- one
to run on PRs and one to run when actually merging commits -- so that
the suggestions are only triggered in the former case. It might be
possible to recombine these using data in the `workflow_run` invocation
to tell them apart, but the documentation here isn't very good so I've
made this PR dump out that event information so that we can look at it
and see if it contains the relevant information.
Jon Ross-Perkins
Richard Smith