The premerge pipeline currently creates an artifacts directory with some
statistics that gets uploaded on the buildkite side for later
inspection. This patch adds support for this on the Github side by using
the upload artifacts action.
Reviewers: Keenuts, lnihlen, mizvekov, tstellar, Endilll
Reviewed By: mizvekov
Pull Request: https://github.com/llvm/llvm-project/pull/135538
This patch bumps workflows depending upon the Linux CI container to
ubuntu 24.04. The 22.04 container is no longer being built as it was
recently bumped to 24.04, so this patch moves all of these workflows
over to the new container to keep them updated and ensure they are using
an actually maintained version of the container image.
- fixes#132303
- Moves dot2add from a language builtin to a target builtin.
- Sets the scaffolding for Sema checks for DX builtins
- Setup DirectX backend as able to have target builtins
- Adds a DX TargetBuiltins emitter in
`clang/lib/CodeGen/TargetBuiltins/DirectX.cpp`
In 0547e573c555, I introduced backdeployment testing on macOS using
Github-provided builders. This was done by basically building libc++ on
a slightly older macOS (like macOS 13) and then running against the
system library on that machine. However, that created a dependency that
libc++ must keep working on macOS 13, which doesn't support the
latest-released Xcode.
This patch solves that problem by moving the deployment testing to a
newer version of macOS which supports the latest-released version of
Xcode.
Sadly, that also reduces the backdeployment coverage we have since we're
not actually testing on older OSes, but is necessary to satisfy the
documented libc++ support policy. In the future, we could improve the
situation by providing a Lit configuration that allows compiling (but
not running) all the tests, building the tests on a supported macOS, and
then shipping those tests on an older backdeployment target in order to
run them against the system library. Since that requires significant
engineering, this isn't done at this time.
The Github runner version got bumped recently and it would be good to keep
this up to date. Also debugging an issue where Github ARC is failing to
create new pods and trying to see if it might be related to outdated
versions.
This patch migrates the CI over to the new compute_projects.py script
for calculating what projects need to be tested based on a change to
LLVM.
Reviewers: lnihlen, ldionne, tstellar, Endilll, joker-eph, Keenuts
Reviewed By: Keenuts, tstellar
Pull Request: https://github.com/llvm/llvm-project/pull/132642
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).
This helps keep things up to date, and should not cause any issues given we do
not need to care about binary compatibility for things built in the CI
container. This patch also changes the name of the container which allows
incrementally moving jobs over after this lands.
Reviewers: tstellar
Reviewed By: tstellar
Pull Request: https://github.com/llvm/llvm-project/pull/132568
This patch bumps the CI container to the latest LLVM Release and gets rid of
the patch that we were carrying that is in 20.1.1.
Reviewers: tstellar
Reviewed By: tstellar
Pull Request: https://github.com/llvm/llvm-project/pull/132567
This is generally good practice if the caches won't be reused (though
arguably pedantic for the `stage1-toolchain` stage).
`docker history` on comparable images showed that this saves a few
hundred MB on stage1, and ~60MB on the `apt-get` layer of
`ci-container-agent`.
This makes things quite a bit simpler and also gets rid of some API
calls. We weren't hitting any API limits, but getting rid of them leaves
more quota for other things should we ever need it. This just diffs the
merge commit in the pull request workflows, which gives the diff for the
PR.
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 bumps most of the workflows to ubuntu 24.04, with the
exception of worklfows that depend on the CI container, which will need
to be updated separately before we are then able to use it for the other
workflows.
This patch fixes the scorecard action. It is currently failing with an
error due to the upload-artifact action being too far out of date.
https://github.com/llvm/llvm-project/actions/runs/13865016326/job/38802095257
is an example of a job failure.
This patch also bumps the other actions versions while we are at it.
In recent versions of Clang, using -std=c++20 (and later) implies LSV
when compiling with modules. This change resulted in making our LSV job
redundant with the regular modules job, which uses the latest Standard.
This patch increases the coverage of our CI without increasing its cost
by pinning the LSV job to use C++17, which normally doesn't use LSV. A
related question is whether we should add coverage for non-LSV builds
using Clang modules.
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.
It seems stefanp-ibm got renamed to sefanp-synopsys. Renaming in the file so
that the release asset audit does not keep flagging this binary. All signs
point to this being the same account. The release is dated to June of 2024,
the name is close enough, and the new account is already in the LLVM org/
has a history of contributions.
This is a stop gap for #130650.
This patch has pins actions in the libc Github workflows. Hash pinning
is a best practice as it ensures we are getting an exact action version,
which can help with reproducibility/reliability. It additionally
alleviates security concerns as an attacker can modify release assets,
potentially giving them access to tokens in privileged workflows.
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).
This patch replaces all instances of ubuntu-latest with ubuntu-24.04
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.
- Trailing whitespace shows up as red on my editor, so remove.
- Docker on my machine warns that having line continuations like:
```
sudo \
foo
```
is deprecated, and will become an error, so fix that up ahead of time.
This patch has pins actions in the libc Github workflows. Hash pinning
is a best practice as it ensures we are getting an exact action version,
which can help with reproducibility/reliability. It additionally
alleviates security concerns as an attacker can modify release assets,
potentially giving them access to tokens in privileged workflows.
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 also fixes test failures in the clang-cl build configs that started
a couple days ago. It seems like the failures were triggered by an update
to the base image on the Github provided runners.
There were failures in test/libcxx/system_reserved_names.gen.py, due to
an issue in an Clang intrinsics header (avx512fp16intrin.h); this issue
was observed and fixed for Clang 19 in 6f04f46927c. The test does
#define A SYSTEM_RESERVED_NAME
which clashes with a parameter with the name `A` in that header.
By upgrading the toolchain to Clang 19, we get fixed version of this
intrinsics header.
Also update the llvm-mingw toolchains to a version with Clang 19.1.7.
As discussed on Discourse
(https://discourse.llvm.org/t/googles-plan-for-the-llvm-presubmit-infrastructure/78940/8),
this patch renames the premerge jobs to include experimental in them to
hopefully better signal that these are still a prototype. This patch
does not mark the MacOS job as experimental as that is being used in
production on the release branch.
I've recently noticed that our CI is bottlenecked around platforms on
which we don't have a lot of capacity like macOS (mostly) and Windows.
To try to alleviate that, this patch moves the macOS builds and the
Windows builds further down the pipeline so that they will get triggered
less often (if an earlier job fails).
This patch gets rid of the file restriction for running the new premerge
Github workflow on PRs. This will cause the jobs to be run on all the
PRs. Currently the jobs will succeed regardless of build/test failure
results. This will let us test the new infra hopefully without too much
disruption before eventually letting jobs fail when builds/tests fail
and deprecating the existing premerge system.
This is part of the launch plan as outlined in
https://discourse.llvm.org/t/googles-plan-for-the-llvm-presubmit-infrastructure/78940.
This patch has pins several actions dependencies in the premerge
workflow and the Windows/Linux container build workflows to help improve
security in the unlikely event that someone tries to pull off a supply
chain security attack by modifying release asserts for these actions.
Before 19, we had releases from release managers, the bot, and community
members. 19 started to restrict this, with only select community members
uploading releases. The lists of users are written out each time to make
modifying this easier.
If we cannot parse the release number, I've made it raise an issue
saying so. Since this may also be a sign of a malicious action.
This patch removes the workflow-scoped package write permissions in the
libcxx-build-containers workflow. The relevant permissions are already
present in the job, so this raises the potential for new jobs being
added to the workflow that do not need the permissions but having them
anyways. Not having workflow-scoped write permissions is security best
practice.
Fixes#126230.
Prior workflow runs were not being cancelled when the pull request was
closed, and I think this was why. Also, there is no advantage to having
the definitions at the job level.
