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

[Louis Dionne via All-commits]

  Branch: refs/heads/users/ldionne/libcxx-benchmarks-inline-build
  Home:   https://github.com/llvm/llvm-project
  Commit: 25968084176203b38394f10c0ddebd46e6781ffd
      https://github.com/llvm/llvm-project/commit/25968084176203b38394f10c0ddebd46e6781ffd
  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-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

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/llvm-project/llvm-project/.github/workflows/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