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.
Flang for Windows depends on compiler-rt, so we need to enable it for
the stage1 builds. This also fixes failures building the flang tests on
macOS.
Fixes#100202.
This patch decouples macOS CI testing from BuildKite, which makes the
maintenance of macOS CI easier and more accessible to all contributors.
Right now, the macOS CI is running entirely on machines owned by the
LLVM Foundation with only a small set of contributors having direct
access to them. In particular, updating these machines is currently
a very time-consuming manual process that requires taking the machines
offline, and using Github-provided instances makes that an order of
magnitude easier.
The story for performing back-deployment testing still needs to be
figured out, so for now we are retaining some jobs under BuildKite.
This workflow produces a list of users that should be moved to the LLVM
Triagers team. An admin will review the list and then manually move
people to the LLVM Triagers Team.
I've also added some documentation to the Developer Policy about the
Triage Role.
See
https://discourse.llvm.org/t/rfc2-new-criteria-for-commit-access/77110
for more details.
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.
This patch bumps the CI container LLVM version to 18.1.8. This should've
been bumped a while ago, but I just noticed that it was out of date.
This also allows us to drop a patch that we manually had to add as it is
by default included in v18.
This automatically adds the `clang:as-a-library` label on PRs for the C
and Python bindings and the libclang library
---------
Co-authored-by: Vlad Serebrennikov <serebrennikov.vladislav@gmail.com>
Previously, #77219 added a `python_version` parameter for the Github
Actions CI Ninja-based build tests. This is necessary to run component
tests on different Python versions, as is currently done by the only
user of this parameter, the [Libclang Python bindings
test](https://github.com/llvm/llvm-project/blob/main/.github/workflows/libclang-python-tests.yml).
The parameter is missing from the concurrency group of the
workflow, meaning that starting the workflow with two different Python
versions immediately cancels one of them, as pointed out by
https://github.com/llvm/llvm-project/pull/77219#issuecomment-1937105822.
This change fixes that problem by making the Python version part of the
concurrency group key, and removes the superfluous concurrency group
from the calling workflow.
This mechanism simply doesn't work for me. I'm getting CCed to
completely unrelated PRs all the time. I checke the bugtracker manually
often enough, so I don't need this.
For reusable workflows, the called workflow cannot upgrade it's
permissions, and since the default permission is none, we need to
explicitly declare 'contents: read' when calling the release-sources
workflow.
Fixes the error:
The workflow is requesting 'contents: read', but is only allowed
'contents: none'.
We need a different attestation for each supported architecture, so
there artifacts all need to have a different name.
The upload step is run on a Linux runner, so no matter which
architecture's binary is being uploaded the runner.os and runner.arch
variables would always be 'Linux' and 'X64' and so we can't use them for
naming the artifact.
python3 wasn't able to see modules installed by pip, so we need to use
the setup-python action to ensure that the default pip and python3 both
use the same prefix.
See https://github.com/actions/runner-images/issues/10385
The old version in the llvm/actions repo stopped working after the
version variables were moved out of llvm/CMakeLists.txt. Composite
actions are more simple and don't require javascript, which is why I
reimplemented it as a composite action.
This will fix the failing abi checks on the release branch.
The old out-of-tree build configuration stopped working and in tree
builds are supported now, so we should use the in tree configuration.
The only downside is we can't run the tests any more, but at least we
will be able to test the build again.
If we pull from the release tag, then if there is a bug in one of the
actions on the release tag, then we can never do a build for that tag.
Pulling from main will allows us to fix bugs in the actions we use to
build the releases.
This adds release binary builds for the 4 platforms currently supported
by the free GitHub Action runners:
* Linux x86_64
* Windows x86_64
* Mac x86_64
* Mac AArch64
The test stages for these are known to fail, but the creating and
upoading of the release binaries should pass.
This checks to ensure that uploads are only made by 'approved'
uploaders, which is just everyone who has uploaded a release asset in
the past.
We could do more, but this is just a simple implementation so we can put
something in place and see how it works.
For more discussion see:
https://discourse.llvm.org/t/rfc-improve-binary-security/78121
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
The PR removes the `*` from the generic MLIR Vector/Linalg rules. The
`*` symbol keeps the match local to the files in the directory,
excluding sub-directories, which was not the intention when I added
these rules.
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
