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.
Add @antiagainst and @kuhar as codeowners for SPIR-V in MLIR. This is to
assign reviewers automatically.
We already have a self-serve mechanism for subscribing to mlir/spirv
issues (@llvm/pr-subscribers-mlir-spirv), but this codeowners change
reflects a narrower set of core authors/maintainers for this part of the
mlir.
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'
