The runners-32 group is broken, for reasons...
The easiest fix is to move the jobs to runners-8.
(which needs to be renamed, because they're all actually 30 core
machines)
There are a few drive-by fixes:
- Since the combination RTTI disabled and exceptions enabled do not
work, this combination is prohibited.
- A small NFC in any fixing clang-tidy.
The code in the Buildkite configuration is prepared for using the std
module. There are more fixes needed for that configuration which will be
done in a separate commit.
For reasons unknown, the FIRST_TIMER and FIRST_TIME_CONTRIBUTOR states
don't come through on new user PRs, I have opened
https://github.com/orgs/community/discussions/78038 to see if that's my
mistake or GitHub's.
In the meantime, a possible workaround is to check that we have none of
the other states. If there's some bug that means the first time
associations aren't available in workflows, maybe the association will
be "NONE".
Also added a debug step to print that association so I can add it to the
linked report. I will remove this as soon as I have 1 example PR.
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.
Add a pre-commit CI workflow for the experimental SPIR-V backend. This
action should only run when SPIR-V target or test files are modified.
The `codegen-spirv` tests don't run as part of `check-all` because the
SPIR-V backend is still experimental.
Depends on #73371 (for a green tree)
It seems the fail fast just doesn't strike the right balance.
It wastes too many resources, especially if a build is killed because
the machine it was running on got preempted.
Instead, we should simply not run any future jobs if a failure has
occured, while letting the already running jobs finish.
This includes some commonly needed information like how to add
reviewers.
This is implemented as a job before the labeler, so that on a new PR the
comment is added before there are any subscribers and only the author
gets a nofitication.
The labeler job depends on the greeter having run or having been
skipped. So if the PR wasn't just opened, or it's from a regular
contributor, the labeling still happens.
But we can be sure that when a greeting comment is left, it's the very
first thing we do.
Github actions has some quirks with how you use runner groups, labels,
names, etc... One of them is that groups can't "group" more than one set
of builders. To do that, you use the same name. So now we're specifying
the name.
We had a scheduled build on buildkite, we probably want something
testing head here as well.
Since this change just adds more tests, I think we can skip pre-commit review.
[skip ci]
This removes the Google hosted Linux buildkite builders. We have since
moved all of them over to github actions.
Follow up changes will be sent for android.
These are unlikely to produce errors in the build, assuming that the
tablegen emitter works as expected, but we're still losing some
documentation build testing coverage but not building upon changes to
these files.
Build clang with the host compiler and ccache enabled in order to speed
up the phase 1 builds. This helps reduce the amount of time spent
running on the non-free builders.
There are ongoing issues with the libc++ bots, some of them seem
related to a new release of the gha action runner controllers.
Until I get this figured out, it's a lot easier to have 99% of the
bots using a single machine shape
I swore I copied the if statement from somewhere, but whatever I did to
it while moving it over dropped one of the equals signs. This patch
fixes that so the action will actually work properly.
Currently, the scorecard action runs on forks. This means that every
recent fork will be periodically running a job that doesn't really make
a lot of sense to run outside the main monorepo. This patch fixes that
by restricting the job to only run in the monorepo.
Currently, when changes are made to the tablegen files that build the
docs, the docs build is not tested. This should rarely cause breakages,
but it's cheap to test and there isn't a major reason not to.
This means that if we try to download a missing file, we do not get a
document with the same file name, but containing only the http response
code.
```
$ curl -O -L --fail https://raw.githubusercontent.com/llvm/llvm-project/main/.github/workflows/not-a-file.py
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 404
$ $?
22: command not found
```
Which will be less confusing than python complaining about the file
contents.
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.
This patch enables building the flang docs in Github actions to enable
rapid iteration in PRs and to catch docs build failures more easily
before merge/after merge. This patch currently doesn't fail for Sphinx
warnings, but the intention is to enable this functionality once the
flang docs are fixed to build without warnings after the transition to
Myst.
This is essentially a revert of
1ed710836a. It is safe to use the
pull_request_target event for pr-subscriber, because it does not
checkout any code from the pull request branch.
This is essentially a revert of
91fdb20915. It is safe to use the
pull_request_target event for new-prs, because it does not checkout any
code from the pull request branch.
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 4aa12afb96.
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 patch enables building the openmp documentation through Github
actions during PRs and at tip of tree to ensure that the documentation
builds and that there aren't any Sphinx warnings in a manner that
enables more rapid developer iteration without having to install
documentation tooling.
https://github.com/llvm/llvm-project/pull/69824 added libc build, but
missed the folder in ninja command, is causing failures.
ninja: fatal: chdir to 'docs-libc-html' - No such file or directory
ninja: Entering directory `docs-libc-html'
This patch adds the lld documentation to the documentation github
actions CI to automatically validate in PRs/at tip of tree that the docs
build and there aren't any Sphinx warnings. There is existing buildbot
coverage for the lld docs, but this much more convienient to use in
cases like PRs.
This patch adds support for building the libc docs in Github actions.
This eanbles easily diagnosing doc build failures/warnings in PRs and at
the tip of tree.
My previous commit 397f1ce9ef switched up
the docs github action to use the GH API for pull requests. However,
this breaks the action when pushing to a branch as the Github API can't
provide diffs for commits. This patch fixes that by creating a local
checkout beforehand on push events for determining the changed files.
People are currently running into issues where the files-changed step
isn't able to find the merge base. This seems to happen more often on
very out of date branches. This patch side steps the issue by just
fetching the diff from the GH API.
This patch adds a step to the documentation Github action to build the
libc++ docs if they have changed. This enables easily diagnosing build
failures/warnings in PRs.
This patch adds the libunwind docs to the Github docs action which
enables easy triage of docs build failures in Github PRs. There is
already buildbot coverage of this configuration, but it is much less
convenient to use in PRs.
There still seem to be issues with the files changed step taking a
significant amount of time on PRs. This seems to be occurring on PRs
with one commit and not on PRs with more than one commit which is why I
didn't catch this nuance before. Either way, fetching an additional
commit seems to fix the issue. Requires a little bit of hackiness due to
the fact that you can't do math in the github actions variables.
Will be monitoring this over the next little bit to see if this actually
fixes the problem.
CI stuff is annoying sometimes.
This patch adds a step to build the lldb docs when they change to the
Github docs action, enabling easy triage of warnings/docs build failures
during the PR process.
This patch adds the clang-tools-extra docs to the Github CI job that
builds docs, enabling the ability to easily ensure the docs build
properly without warnings in PRs and at the tip of tree.
