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.
The comment was originally added in
b3af755254599f474601d0d7b7374dcc36af279a, but
2898c3e0bbf904c68efb194525bcdfeedb3014c2 greatly simplified things
making the previous comment invalid. We no longer need to look at
diffing main versus the PR and whether we are doing a two dot or three
dot diff as we are just diffing the merge commit.
This patch changes getting changed files in the pr code format job to
just checking out the previous two commits (the merge commit and its
porent, the current commit latest in main), which allows us to just diff
the merge commit. This means we do not have to checkout the ref through
the merge base, which should save approximately a minute per job (or
much more in some cases where the PR is particularly out of date).
The tj-actions/changed-files repo has been taken down to the security
incident
(https://www.stepsecurity.io/blog/harden-runner-detection-tj-actions-changed-files-action-is-compromised).
This patch moves these jobs over step-security's fork, which has been
loosely audited and has had the malicious commits removed. This is
mainly intended as a stop-gap to get these actions running again while
we figure out the best path forward.
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).
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.
The version of clang-format we use in the CI to format all PRs is a bit
outdated, leading to some confusion when the CI job produces different
output from what people have locally.
This patch sets the timeout of the code formatting job to 30 minutes.
The job is currently failing in specific circumstances and needs to be
reworked, but as a temp hack, change the timeout to 30 minutes so that
we can catch these jobs before they hit the Github Actions timeout limit
of six hours.
Somewhat (hackily) alleviates #79661 slightly.
Currently the formatter only runs for the main branch, which prevents
the formatter from running for stacked PRs, which have to target user
branches instead of main.
Since clang-format 18.1.4, there have been a number of commits that
fixed various kinds of issues:
- Bug
3ceccbdb1995
- Regression
6dbaa89433f7
51ff7f38b633
35fea1032741
7699b341b763
768118d1ad38
8c0fe0d65ed8
- Crash
f1491c7460e7
- Invalid code generation
0abb89a80f5c
We currently receive a warning on all Github Actions workflows that use
`setup-python`, since they all use v4 of the action, which uses the
deprecated Node.js 16. This PR upgrades the action in all places to v5,
which uses Node.js 20 (see [setup-python release
page](https://github.com/actions/setup-python/releases/tag/v5.0.0))
The recent change to split the PR code formatting job accidentally
misspelled the repository field when specifying the repository to fetch
the code formatting utils from. This patch fixes the spelling so that
the job does not throw a warning and clones the tools from the specified
repository.
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 dec63221d56e8092557f29f1f2c127828d7521bb.
This probably needs more discussion before we can land it. The consensus
(from what I can gather) in https://discourse.llvm.org/t/rfc-clang-format-all-the-things/76614
is that we should be careful with version upgrades for consistency.
A recent comment modified the job to only run on the main branch, but
the formatting was slightly off, causing the job to not run. This patch
fixes the formatting so the job will run as expected.
Modifying a cherry-picked patch to fix code formatting issues can be
risky, so we don't typically do this. Therefore, it's not necessary to
run this job on the release branches.
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
This patch sets the start revision to the merge base so that the c++
formatting action won't produce any diffs related to changes in main but
not in the PR branch. This also leaves a TODO to migrate over to the
--diff_from_common_commit option in git-clang-format once LLVM v18 is
released.
Checking out a ref of the branch requires the remote to be the same as
the fork whereas setting it to be the commit SHA allows for us to avoid
changing the remote. This should fix the action not working on PRs made
from forks (essentially all of them).
This commit adds another step to the Github workflow that runs the code
formatting check to fetch through the merge base. This ensures that the
necessary history is present to find the changed files and also to run
clang-format over. This change massively increases the speed of the
action (~10 minutes down to ~2 minutes in most cases from my testing)
and also increases the reliability significantly.
There are currently a couple jobs that run on all forks of LLVM too (if
there is a PR opened, or in the case of the documentation builds, upon
pushing to main). This isn't desired behavior. This commit disables that
behavior, forcing the jobs to not run if they aren't running against
llvm/llvm-project or a PR against that repo.
We've gotten ~750 commits in the last 7 days. Upping the fetch depth to
2000 will make it more likely that PRs up to 2 weeks old will have
enough fetch history to find a common parent. This _might_ address some
of the failures we're seeing in the clang-format action where it cannot
find a common base commit.
This reverts commit 4aa12afb967bd7c5f051f3b72271f787f1a7538b.
This change introduced failures upon checking out the PR source code.
Pulling this out of tree while I investigate further.
This patch makes a couple changes to the PR code formatting check:
- Moves the `changed-files` action to before the checkout to make sure
that it pulls
information from the Github API rather than by running `git diff` to
alleviate some
performance problems.
- Checkout the head of the pull request head instead of the base of the
pull request
to ensure that we have the PR commits inside the checkout.
- Add an additional sparse checkout of the necessary LLVM tools to run
the action
to alleviate security problems introduced by checking out the head of
the pull
request. Only code from the base of the pull request runs.
- Adjust the commit references to be based on `HEAD` as Github doesn't
give
exact commit SHAs for the first commit in the PR.
This reverts commit 80b2aac2c671771d74bc5d7426f7bd4ffa0b8a8e.
I mistakenly assumed this job didn't also do python formatting
(should've grepped for more than just black in the python portion of
this script). Pulling it out for now to get python formatting working
again while the patch is iterated further.
Currently the PR formatting job only runs clang-format. There isn't a
lot of utility in running it if there aren't any C/C++ changes as there
will be nothing to format. This isn't super noisy currently as the job
doesn't fail if there aren't any C/C++ changes, but it's a bit of a
waste.
In addition, this patch names the code formatting job "Check C++
Formatting" to make it clear that this job only checks C/C++ formatting
rather than Python formatting/other languages.
I landed this format helper, but unfortunately, it didn't work because
of permissions, it could not add comments on a fork's PR. @cor3ntin
informed me there are fixes for this that you had worked on @tstellar -
but I didn't have time to read up on it too much. Can you explain what
changes are needed to get the action to be able to write comments on
fork's PR?
This helper will format python files with black/darker and
C/C++ files with clang-format.
The format helper is written so that we can expand it with new
formatters in the future like clang-tidy.
