Skip to content

[Github][Bazel] Add Workflow to Run Bazel Build #165071

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Nov 7, 2025
Merged

[Github][Bazel] Add Workflow to Run Bazel Build #165071

Changes from 5 commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
9697dab
[Github][Bazel] Add Workflow to Run Bazel Build
boomanaiden154 Oct 25, 2025
8ef3b0a
fix1
boomanaiden154 Oct 25, 2025
862d768
fix2
boomanaiden154 Oct 25, 2025
32dd8d9
fix3
boomanaiden154 Oct 25, 2025
b707355
fix4
boomanaiden154 Oct 25, 2025
8a07ad0
feedback
boomanaiden154 Nov 1, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 25 additions & 0 deletions .github/workflows/bazel-checks.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -30,3 +30,28 @@ jobs:
- name: Run Buildifier
run: |
buildifier --mode=check $(find ./utils/bazel -name *BUILD*)

bazel-build:
name: "Bazel Build/Test"
runs-on: llvm-premerge-linux-runners
if: github.repository == 'llvm/llvm-project'
steps:
- name: Fetch LLVM sources
uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
# TODO(boomanaiden154): We should use a purpose built container for this. Move
# over when we have fixed the issues with using custom containers with Github
# ARC in GKE.
- name: Setup System Dependencies
run: |
sudo apt-get update
Copy link
Member

@aaronmondal aaronmondal Oct 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems risky. Unless this is pinned, it'll be very cache inefficient since apt installs are not reproducible by default. Even with pinning, i believe since the installs contain timestamps it would still not be possible to reuse the cache like this. IIRC tools like the OSSF scorecard would flag this as "critical level" risk as it essentially allows whatever tooling to end up on this runner and AFAICS the llvm-premerge-linux-runners aren't pinned either.

Another thing is that this fairly heavily creates a dependence on ubuntu and the particular configuration of the runner.

I guess if it's only temporary I don't have too much of an opinion against this, but I think it's worth mentioning that this really shouldn't stay like this forever.

Regarding a more long-term solution, my vote would be on a nixos image as that not only freezes deps properly, but is also verifiable for external users, i.e. from a configuration file it'll be possible to bit-by-bit reproduce the runner image by third parties. This gives essentially perfect cache-reuse and makes things comparatively easily verifiable.

I believe i have such an image lying around somewhere. If there is interest, i can take another look or set up a new one for this usecase.

For just the initial implementation, though it seems unintuitive, it might be an option to actually just remove the apt update call. I'm not sure whether this works with the default llvm-premerge runners, but if it does, it would at least pseudo-pin the apt repo to whatever version is on those runners which might be a bit more stable than updating everytime this workflow runs.

Copy link
Contributor Author

@boomanaiden154 boomanaiden154 Nov 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems risky. Unless this is pinned, it'll be very cache inefficient since apt installs are not reproducible by default. Even with pinning, i believe since the installs contain timestamps it would still not be possible to reuse the cache like this.

They're not reproducible, but it should be good enough. A stable release of ubuntu is not going to release package updates that often, and for the libraries that we depend on, they're probably getting updated less than changes to LLVM headers invalidates most of the cache. We also have a workflow (https://github.com/google/gematria/blob/3ba6877cc9ebb93160ddd05a1fe4b4d33bbf8067/.github/workflows/main.yaml#L115) where we set up libraries/the toolchain within the job and caching just works fine. Bazel caching based on timestamps would also be news to me.

IIRC tools like the OSSF scorecard would flag this as "critical level" risk as it essentially allows whatever tooling to end up on this runner and AFAICS the llvm-premerge-linux-runners aren't pinned either.

This would not be flagged by OSSF scorecard. It's not a huge risk given the packages get verified against the keys installed in the image. Of course someone's key can get compromised, but they should be a fairly rare occurrence.

Another thing is that this fairly heavily creates a dependence on ubuntu and the particular configuration of the runner.

Sure, but any other setup will create a dependence on that specific configuration. If we want to fix this, we should probably make the bazel build itself more hermetic. The goal of this workflow is also to check that the bazel build works. Not to enable caching across setups or ensure the results are bit for bit reproducible outside of the CI.

For just the initial implementation, though it seems unintuitive, it might be an option to actually just remove the apt update call. I'm not sure whether this works with the default llvm-premerge runners, but if it does, it would at least pseudo-pin the apt repo to whatever version is on those runners which might be a bit more stable than updating everytime this workflow runs.

I'm not sure why you call this unintuitive. This does not work on the llvm-premerge-linux-runners because we clear the apt cache when building the container image. This is also not guaranteed to work as the repos change.

Copy link
Collaborator

@rupprecht rupprecht Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With regards to version pinning, this is only an issue because of mprf/pfm, right? If reproduciblity becomes an issue, we could drop those and have --config=ci configured to use the in-tree versions instead of the system-provided ones. It would make things slower, but more hermetic.

Copy link
Contributor Author

@boomanaiden154 boomanaiden154 Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, those would be the only two external dependencies. We also depend on the system provided standard libraries, but those will remain consistent within a single container version. I don't think this will be a large issue though as I don't think MPFR/PFM get upgraded often at all in the stable distros compared to the rate at which LLVM changes to make a big difference cache rate wise.

Making the build more hermetic might be nicer in itself though, but not sure it matters too much for what we're trying to do here.

sudo apt-get install -y libmpfr-dev libpfm4-dev
sudo curl -L https://github.com/bazelbuild/bazelisk/releases/download/v1.27.0/bazelisk-amd64.deb > /tmp/bazelisk.deb
sudo apt-get install -y /tmp/bazelisk.deb
rm /tmp/bazelisk.deb
- name: Build/Test
working-directory: utils/bazel
run: |
bazel test --config=ci --sandbox_base="" \
@llvm-project//llvm/... \
@llvm-project//clang/... \
@llvm-project//mlir/...
Copy link
Collaborator

@rupprecht rupprecht Oct 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This patch only tests a couple projects just to get things going. The plan is to expand to more projects eventually and setup a GCS bucket for caching so jobs complete quickly by using cached artifacts.

llvm+clang+mlir is most of targets already. If you want to get this running w/ a minimal config and only add other projects once we have caching, should we start smaller? e.g. just @llvm-project//llvm/unittests:adt_tests

Copy link
Contributor Author

@boomanaiden154 boomanaiden154 Nov 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. It's not actually too much time to run this set, but switched to the unittests for now to get things going.

Loading