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
This job uses the new artifact attestations:
https://github.blog/2024-05-02-introducing-artifact-attestations-now-in-public-beta/
This will allow users to verify that the sources came from a specific
workflow run in the llvm-project repository. Currently, this job does
not automatically upload sources to the release page, but rather it
attaches them the workflow run as artifacts. The release manager is
expected to download, verify, and sign the sources before uploading them
to the release page.
We may be able to automatically upload them in the future once we have a
process for signing the binaries within the github workflow.
Technically, though, the binaries are being signed as part of the
attestation process, but the only way to verify the signatures is using
the gh command line tool, and I don't think it is best to rely on that,
since the tool may not be easily available on all systems.
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))
Pick the latest version available in Chocolatey (18.1.6) and llvm-mingw
(20240606, which includes LLVM 18.1.7).
Also add the flag "--allow-downgrade" when installing a specific version
of LLVM. If the preinstalled version is higher than the requested one,
Chocolatey would otherwise error out when requesting installing a lower
version. This will avoid errors in the future, if the runner image comes
preinstalled with a newer version of LLVM.
(This currently seems to happen with a recent version of the GitHub
Actions runner image, version 20240610.1.0 has LLVM 18.1.6 already
preinstalled, and will error out when trying to install the 17.0.6
version that we previously requested.)
This job will run once per day on the main branch, and for every commit
on a release branch. It currently only builds llvm, but could add more
sub-projects in the future.
OpenSSF Best Practices recommends running a static analyzer on software
before it is released:
https://www.bestpractices.dev/en/criteria/0#0.static_analysis
In order to make the behavior of the libc++ restarter more visible
to users, this change creates a check run on the considered workflow
to let users know what action, if any, was taken
I've been running a cronjob on my local machine to restart preempted
libc++ CI runs. This is bad and brittle. This upstreams a much better
version of the restarter.
It works by matching on check run annotations looking for mention
of the machine being shutdown.
If there are both preempted jobs and failing jobs, we don't restart
the workflow. Maybe we should change that?
This updates the release-binaries workflow so that the different build
stages are split across multiple jobs. This saves money by reducing the
time spent on the larger github runners and also makes it easier to
debug, because now it's possible to build a smaller release package
(with clang and lld) using only the free GitHub runners.
The workflow no longer uses the test-release.sh script but instead uses
the Release.cmake cache. This gives the workflow more flexibility and
ensures that the binary package will always be created even if the tests
fail.
This idea to split the stages comes from the "LLVM Precommit CI through
Github Actions" RFC:
https://discourse.llvm.org/t/rfc-llvm-precommit-ci-through-github-actions/76456
Add wheel publishing in addition to existing source distribution
publishing of lit.
Fixes#63369. This also uses the exact fix proposed by @EFord36 in
#63369.
Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
Since we have released Clang 16 is no longer actively supported. However
the FreeBSD runner is still using this, so some tests still guard
against Clang 16.
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.
I'm hoping this will fix the errors we've been seeing the last few days:
2024-03-19T20:44:07.4841482Z 2024/03/19 20:44:07 error signing scorecard
json results: error signing payload: getting key from Fulcio: verifying
SCT: updating local metadata and targets: error updating to TUF remote
mirror: invalid key
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.
