[llvm] [Github][Bazel] Add Workflow to Run Bazel Build (PR #165071)

[Aiden Grossman via llvm-commits]

================
@@ -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 at 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
----------------
boomanaiden154 wrote:

> 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.

https://github.com/llvm/llvm-project/pull/165071