[all-commits] [llvm/llvm-project] cb2366: [libc++] Inline the build-at-commit composite acti...

[Louis Dionne via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: cb23668ed2c1a876db0eb0284b7aa15e0b1258d4
      https://github.com/llvm/llvm-project/commit/cb23668ed2c1a876db0eb0284b7aa15e0b1258d4
  Author: Louis Dionne <ldionne.2 at gmail.com>
  Date:   2026-09-30 (Wed, 30 Sep 2026)

  Changed paths:
    M .github/workflows/libcxx-benchmark-commit.yml
    M .github/workflows/libcxx-benchmark-libstdcxx.yml
    M .github/workflows/libcxx-pr-benchmark.yml
    R .github/workflows/libcxx/build-at-commit/action.yml

  Log Message:
  -----------
  [libc++] Inline the build-at-commit composite action into the benchmark workflows (#227750)

Yet another twist in the endless saga of setting up performance
benchmarking infrastructure for libc++. Since the recent switch to
Kubernetes runners, there are now two layers of "pods". First, there's
the runner pod which executes the Github action itself. It's the one
that loads the Docker image specified in the Github workflow and then
launches it.

Then, there's the workflow/job pod, which executes the actual Docker
image and the commands described in `steps` in the workflow file.

This causes problems because the workflow pod is the only one that has
access to the checked out monorepo (since it's checked out within the
running Docker container). This means the runner pod does not have
access to composite actions stored in the repository, which leads to
errors like:

  Can't find 'action.yml', 'action.yaml' or 'Dockerfile' under '/home/runner/_work/<...>/libcxx/build-at-commit'.

IIUC, the consequence is that we can't use composite actions from these
runners, basically. Consequently, this patch goes back to hardcoding the
build-at-commit command in the benchmarking jobs.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications