Problem
With gh-aw v0.88.4 and sandbox.agent.runtime: docker-sudo-iptables, a Ruby selected by ruby/setup-ruby is still not used inside AWF.
This is a follow-up to #57950 / #58311. The v0.88.4 change prevents cached runtimes from overriding an already-correct AWF PATH, but in this runtime profile the selected setup-action path does not appear to reach AWF in the first place.
Configuration
runtimes:
ruby:
version: default
sandbox:
agent:
runtime: docker-sudo-iptables
mounts:
- /opt/hostedtoolcache:/opt/hostedtoolcache:ro
The repository's .ruby-version contains 3.4.8.
Environment:
- Runner:
ubuntu-latest
- gh-aw/compiler:
v0.88.4 (82239c030d6a1ef6ec8b87a80a1346eeef211f8d)
- AWF:
0.28.13
- Engine: Pi
0.84.1
- Expected Ruby:
3.4.8
- Actual Ruby inside AWF:
3.2.3
Evidence
The generated workflow's Setup Ruby step succeeds:
Using 3.4.8 as input from file .ruby-version
Entries added to PATH to use selected Ruby:
/opt/hostedtoolcache/Ruby/3.4.8/x64/bin
/opt/hostedtoolcache/Ruby/3.4.8/x64/bin/ruby --version
ruby 3.4.8 ...
The first Ruby check inside the agent reports:
runtime=3.2.3
expected=3.4.8
The generated AWF invocation uses:
sudo -E awf ... --env-all ...
Inside AWF, v0.88.4 then runs the corrected cache fallback:
GH_AW_TOOL_BINS="$(find "$RUNNER_TOOL_CACHE" -maxdepth 5 -type d -name bin ...)"
export PATH="$PATH${GH_AW_TOOL_BINS:+:}$GH_AW_TOOL_BINS"
Appending is correct, but the existing AWF PATH already resolves /usr/bin/ruby (Ubuntu Ruby 3.2.3), not the Ruby 3.4.8 path selected by the setup action.
Likely cause
sudo's secure_path appears to remove the runner's $GITHUB_PATH additions before AWF captures the host path. This is consistent with gh-aw's own comments that sudo may strip core.addPath() additions, but the run artifact redacts AWF_HOST_PATH, so this mechanism is not directly proven by the available logs.
The regression test added in #58311 executes GetNpmBinPathSetup() with an already-correct synthetic PATH. It verifies append ordering, but does not exercise the preceding sudo -E awf boundary or the docker-sudo-iptables runtime profile.
Expected behavior
A runtime selected through:
runtimes:
ruby:
version: default
should remain active inside AWF when using the documented docker-sudo-iptables runtime. Cache-only tools should remain discoverable without allowing /usr/bin/ruby or another cached Ruby to override the selected version.
Suggested regression coverage
Compile and execute, or otherwise model, the docker-sudo-iptables invocation path including the privileged AWF boundary. Assert that a setup-action Ruby path survives into AWF_HOST_PATH and remains ahead of both /usr/bin and other hosted-toolcache Ruby versions.
Problem
With gh-aw v0.88.4 and
sandbox.agent.runtime: docker-sudo-iptables, a Ruby selected byruby/setup-rubyis still not used inside AWF.This is a follow-up to #57950 / #58311. The v0.88.4 change prevents cached runtimes from overriding an already-correct AWF
PATH, but in this runtime profile the selected setup-action path does not appear to reach AWF in the first place.Configuration
The repository's
.ruby-versioncontains3.4.8.Environment:
ubuntu-latestv0.88.4(82239c030d6a1ef6ec8b87a80a1346eeef211f8d)0.28.130.84.13.4.83.2.3Evidence
The generated workflow's
Setup Rubystep succeeds:The first Ruby check inside the agent reports:
The generated AWF invocation uses:
Inside AWF, v0.88.4 then runs the corrected cache fallback:
Appending is correct, but the existing AWF
PATHalready resolves/usr/bin/ruby(Ubuntu Ruby 3.2.3), not the Ruby 3.4.8 path selected by the setup action.Likely cause
sudo'ssecure_pathappears to remove the runner's$GITHUB_PATHadditions before AWF captures the host path. This is consistent with gh-aw's own comments thatsudomay stripcore.addPath()additions, but the run artifact redactsAWF_HOST_PATH, so this mechanism is not directly proven by the available logs.The regression test added in #58311 executes
GetNpmBinPathSetup()with an already-correct syntheticPATH. It verifies append ordering, but does not exercise the precedingsudo -E awfboundary or thedocker-sudo-iptablesruntime profile.Expected behavior
A runtime selected through:
should remain active inside AWF when using the documented
docker-sudo-iptablesruntime. Cache-only tools should remain discoverable without allowing/usr/bin/rubyor another cached Ruby to override the selected version.Suggested regression coverage
Compile and execute, or otherwise model, the
docker-sudo-iptablesinvocation path including the privileged AWF boundary. Assert that a setup-action Ruby path survives intoAWF_HOST_PATHand remains ahead of both/usr/binand other hosted-toolcache Ruby versions.