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

[Aaron Siddhartha Mondal 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
----------------
aaronmondal 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. 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.

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