https://github.com/actions/checkout/releases/tag/v5.0.0 was released a
couple of days ago (still new, sufficient bake time that there probably
is not a significant security issue). There are few changes, with the
most notable ones being dependency bumps, specifically the node version
bump to v24. This requires actions runner v2.327.1. I will land this
after all of the infrastructure has been moved over to the new runner
version.
This patch bumps the actions script version in the issue-write workflow
to v7. This was done before but rolled back due to errors as there were
breaking changes in v5
(https://github.com/actions/github-script#breaking-changes-in-v5). This
was reverted in f984b47.
This patch makes the necessary changes to prevent job failures.
Fixes#130211.
This patch reverts that upgrade which was performed in
74df2032d467618a9aab085120539e306f21bcc0. This broke the workflow, presumably
due to the breaking changes introduced in v5 of this action.
This is a stop-gap for #130211.
This patch replaces all instances of ubuntu-latest with ubuntu-24.04
(outside of the entries in libc++) based on the guidelines in the LLVM
CI best practices doc (https://llvm.org/docs/CIBestPractices.html).
These two actions are particularly old, and should be updated to the
latest version. Doing this in a specific commit to easily roll back if
things break and to get as much testing done as possible within the jobs
triggered as a part of these changes.
This patch haspins all actions in most of the LLVM Github workflows.
This is something we try to do, but no one has gone through and combed
through all of the workflows before this patch.
Notably, this patch does not bump any major versions of actions just in
case there are subtle breaking changes introduced between versions that
could impact us. Also, this patch omits the libc/libc++ workflows so
that they can be split into separate PRs for the respective subproject
maintainers to review.
This patch makes the issue write workflow only run after success or
failure of the workflow invoking it, preventing it from running where
the original workflow was skipped.
Fixes#97294
Actions triggered by pull_request_target events have access to all
repository secrets, so it is unsafe to use them when executing untrusted
code. The pr-code-format workflow does not execute any untrusted code,
but it passes untrused input into clang-format. An attacker could use
this to exploit a flaw in clang-format and potentially gain access to
the repository secrets.
By splitting the workflow, we can use the pull_request target which is
more secure and isolate the issue write permissions in a separate job.
The pull_request target also makes it easier to test changes to the
code-format-helepr.py script, because the version of the script from the
pull request will be used rather than the version of the script from
main.
Fixes#77142
This reverts commit bc06cd5cbcfc22dd976f6742d10bc934e1353b8a.
This caused the job to fail for PRs which still had an older version
of code-format-helper.py in their tree.
Actions triggered by pull_request_target events have access to all
repository secrets, so it is unsafe to use them when executing untrusted
code. The pr-code-format workflow does not execute any untrusted code,
but it passes untrused input into clang-format. An attacker could use
this to exploit a flaw in clang-format and potentially gain access to
the repository secrets.
By splitting the workflow, we can use the pull_request target which is
more secure and isolate the issue write permissions in a separate job.
The pull_request target also makes it easier to test changes to the
code-format-helepr.py script, because the version of the script from the
pull request will be used rather than the version of the script from
main.
Fixes#77142
