fix: carry coreutils as action inputs so apko actions run on minimal executors

[xnox]

Summary

Makes the apko_image / apko_show_config actions runnable on remote executors that don't ship a userspace, and adds a CI job that proves it end to end.

The run_shell actions in copy_to_workdir and apko_image call mkdir, cp, mktemp, find, ln and rm resolved from the executor's PATH. That's fine on a conventional RBE image and fails on a minimal one. This takes the binary from aspect_bazel_lib's coreutils toolchain and declares it in tools, so it's uploaded as an action input and travels to whichever executor the action lands on.

aspect_bazel_lib is already a bazel_dep here and registers that toolchain in its own non-dev section, so this adds no dependency and needs no registration. The Linux assets are statically linked against musl, so they need nothing from the executor either.

Please read: this stacks on #379

This branch contains #379 (@jeffpignataro) unchanged — ddf0245, f1cdd83, f3d1a6d — because the fix here is only reachable once that PR removes no-remote-exec from the apko action. Credit for the remote-execution work and the read-only---cache-dir diagnosis is theirs; I've added no changes to those commits.

If #379 lands first, I'll rebase and this drops to two .bzl files plus the workflow. Happy to split it into two PRs, or to close this and send the coreutils change against #379's branch instead — whichever is easier to review. I opened jeffpignataro#1 with the workflow alone for the same reason.

Evidence

CI job runs actiond, a local Remote Execution API worker that boots a Linux VM on the runner and executes each action inside an empty chroot in it. No account, no secrets, no external service. It's a strict test of the property this PR is about: the chroot ships /bin/bash and an /usr/bin/env stub, and nothing else.

Before this change, both call sites failed at exit 127 — staging with mkdir: command not found, and the apko action with mktemp: command not found. After:

INFO: 6 processes: 1 internal, 5 remote.
INFO: Build completed successfully, 6 total actions

Green run. 5 of 6 processes executed in the VM, nothing local, --remote_local_fallback=false — a full two-arch apko image build inside an empty chroot.

x86_64 only. GitHub's arm64 Linux runners have no /dev/kvm — the Azure DPDsv6 SKU doesn't support nested virtualization, confirmed by GitHub staff — and macOS arm64 can't nest under Apple's Virtualization Framework. actiond's own CI has the same split.

Test plan

• bazel test //... — 6/6, including //docs:update_*_test, so stardoc output is unchanged
• e2e/smoke — 4/4, including fix: restore remote execution support for apko_image #379's lock_hermetic_env (use_default_shell_env = False)
• bazel run //.github/workflows:buildifier.check — clean
• The actiond job above

Note that bazel test //... does not exercise this: locally every action runs on a host that has coreutils regardless. Those runs prove no regression, not that the fix works. The actiond job is the only thing that covers it, which is the argument for keeping it.

Notes

• The find … -exec ln -s mirror added in fix: restore remote execution support for apko_image #379's last commit collapses to a single cp -Rs — same effect (real directories, per-file symlinks into the read-only input tree), and it avoids find, which uutils doesn't ship. So that PR's optimization survives rather than reverting to a full copy.
• These actions still need a shell. On actiond that means --remote_default_exec_properties=requires-bash=, a user-side flag. I deliberately did not bake exec_properties = {"requires-bash": ""} into the rules — it's executor-specific and doesn't belong in a general-purpose ruleset. Going fully shell-free would mean replacing copy_to_workdir with copy_to_directory and giving the apko action a wrapper binary; happy to do that separately if you want it.
• actiond publishes no build provenance, so the workflow's sha256sum -c only proves the download is intact. Worth weighing before this becomes a required check.

🤖 Generated with Claude Code

[jeffpignataro]

I like this tweak. It seems solid and worked fine on our internal RBE.

One note my 🤖 had was that there is a regression for Bazel 7/8 users. WORKSPACE mode does fail at analysis with No matching toolchains found for @@aspect_bazel_lib//lib:coreutils_toolchain_type because the snippet never registers the coreutils toolchain.

Users can fix this independently by registering the toolchain or it gave the option of bumping the toolchain internally - although this would probably be considered a breaking change/major ver bump so may not be worth it.

From 🤖:
In apko/repositories.bzl, bump the pinned aspect_bazel_lib from 1.34.5 → 2.22.5, and have rules_apko_dependencies() itself call register_coreutils_toolchains() — registering inside the existing function means existing users' WORKSPACE files keep working with zero edits when they upgrade. (Registration can't literally live inside the same .bzl without a load-ordering issue — @aspect_bazel_lib must be fetched first — so in practice it's a second load + call in the published snippet, which is the one edit users would need if it can't be folded in.)

[thesayyn]

please see the conversation on other thread about use of symlinks here.

[jeffpignataro]

🚀 pending the small tweak to the symlink behavior for efficiency. If you want to pull that commit in then we can just merge this one and I'll close the other. Thanks!!