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.
After the changes in 89001d1de8ecf03c8820594ea03345b99560272a, the
container pushes failed, because it was attempting to push the same
container twice. This fixes the sed expression used to push the :latest
alias for each container.
This also changes the container version numbers in the tag from unix
timestamps to the abbreviated commit hash for the workflow. This ensures
that the amd64 and arm64 containers have the same tag.
For amd64 we now generate 4 tags:
* ghcr.io/llvm/ci-ubuntu-22.04:latest
* ghcr.io/llvm/ci-ubuntu-22.04:$GITHUB_SHA
* ghcr.io/llvm/amd64/ci-ubuntu-22.04:latest
* ghcr.io/llvm/amd64/ci-ubuntu-22.04:$GITHUB_SHA
For arm64 we generate 2 tags:
* ghcr.io/tstellar/arm64v8/ci-ubuntu-22.04:latest
* ghcr.io/tstellar/arm64v8/ci-ubuntu-22.04:$GITHUB_SHA
Using ccache relies on the GitHub Actions Cache, which may be
susceptible to cache poisoning. See
https://adnanthekhan.com/2024/05/06/the-monsters-in-your-build-cache-github-actions-cache-poisoning/
Even though these attacks may be difficult, it's better to err on the
side of caution and ensure that the build environment for our releases
is as isolated as possible. Additionally, ccache was only being used for
the stage1 build, which is a small part of the overall build, so the
speed up from using it was not that large.
This patch adds a windows premerge job for testing. We plan to enable
this by default soon once we have evaluated stability and have
reasonable reason to believe the system is reliable.
This patch bumps the runner version to v2.322.0 in the CI containers.
Nothing looks suspicious in the change log, and it is important to keep
the runner up to date or we will end up with containers that cannot
connect to Github due to having a version too old.
This reverts commit 106f1056991317af7eaaf19239de93942ac37267.
Everything should be in working order now that the container job has been
updated to work properly. This has been tested on an individual job.
This patch makes the build container job save the agent container image to a
separate tar file rather than bundling it in with the existing tar file. For
some reason, running podman save with two container images and then loading
that single tar file gets rid of the agent image and we end up with two
copies of the original image. This means that premerge jobs will fail with
the agent image because they cannot find the run.sh script.
Trying to switch over to the normal execution mode and running into issues.
Turning this off on main for now while I investigate given my time
availability is a bit sparse today.
This patch removes the container from the premerge job. We are moving
away from the kubernetes executor back to executing everything in the
same container due to reliability issues. This patch updates everything
in the premerge job to work.
This is part of a temp fix to
https://github.com/llvm/llvm-zorg/issues/362.
It appears that introducing docker containers has broken the restarter
job since additional failure messages appear with the preemption
messages.
This should get jobs restarting on preemption again, but may do so
for jobs that also contain unrelated failures
Ahead of GitHub's
[deprecation](https://github.blog/changelog/#artifacts-v3-brownouts) of
v3 versions of both the `upload-artifact` and `download-artifact`
action, I suggest this PR, which bumps the used version of both actions
in all workflows to the newest v4 revision. Additionally, the versions
are hashpinned as suggested in f3524e9aebbfabed0c60d0087b39ce14d8f778da.
This patch fixes a typo impacting functionality and also adds the relevant
variables to the step outputs list so they can actually get picked up by the
push container step.
