Avoid exporting PATH through GITHUB_ENV

[kjanat]

setupPath() currently removes entries containing ruby by exporting a complete
replacement PATH/Path through GITHUB_ENV, then adds the selected Ruby paths
separately through GITHUB_PATH:

setup-ruby/common.js

Lines 371 to 393 in 95ef2b0

	export function setupPath(newPathEntries) {
	const originalPath = process.env[PATH_ENV_VAR].split(path.delimiter)
	let cleanPath = originalPath.filter(entry => !/\bruby\b/i.test(entry))
	core.group(`Modifying ${PATH_ENV_VAR}`, async () => {
	// First remove the conflicting path entries
	if (cleanPath.length !== originalPath.length) {
	console.log(`Entries removed from ${PATH_ENV_VAR} to avoid conflicts with default Ruby:`)
	for (const entry of originalPath) {
	if (!cleanPath.includes(entry)) {
	console.log(` ${entry}`)
	}
	}
	core.exportVariable(PATH_ENV_VAR, cleanPath.join(path.delimiter))
	}
	console.log(`Entries added to ${PATH_ENV_VAR} to use selected Ruby:`)
	for (const entry of newPathEntries) {
	console.log(` ${entry}`)
	}
	})
	core.addPath(newPathEntries.join(path.delimiter))

This appears to work at process-launch time, but it creates two independently
managed sources of PATH state in the Actions runner. In particular, downstream
action log headers show the replacement value from GITHUB_ENV without the Ruby
paths managed through GITHUB_PATH.

Example public job:

https://github.com/kjanat/actions-shells/actions/runs/33935875402/job/101223659801

On macOS, setup-ruby reports:

Entries removed from PATH to avoid conflicts with default Ruby:
  /opt/homebrew/lib/ruby/gems/3.4.0/bin
  /opt/homebrew/opt/ruby@3.4/bin
Entries added to PATH to use selected Ruby:
  /Users/runner/hostedtoolcache/Ruby/3.4.10/arm64/bin

The immediately following action's logged environment contains the cleaned
PATH, but not the selected Ruby directory. Every later logged PATH has the
same shape. Nevertheless, the effective process environment is correct:

runtime:            ruby
command:            /Users/runner/hostedtoolcache/Ruby/3.4.10/arm64/bin/ruby
version:            ruby 3.4.10 ...

Windows exhibits the same split representation: the logged Path omits the
new Ruby/MSYS2 entries while later processes resolve Ruby 3.4.10 correctly.
Linux does not export a replacement PATH in this job because there were no
Ruby-named entries to remove, so it does not exhibit the confusing split.

There is no runtime failure demonstrated here. The concern is that exporting a
snapshot of the complete shared PATH from a reusable setup action is fragile:

• it mixes a literal job environment value with the runner's separately tracked
  prepend-path state;
• downstream action logs do not show the effective process PATH;
• removal from the exported snapshot does not obviously remove matching entries
  already retained by the runner's prepend-path state;
• behavior depends on runner merge/order and Windows environment-key handling.

Could setup-ruby avoid exporting the complete PATH through GITHUB_ENV and
only prepend the selected Ruby through GITHUB_PATH? Since the selected Ruby is
prepended, it should win command lookup without removing unrelated PATH state.
If removal is required for a case that prepending does not handle, it would be
helpful to document why this split mutation is safe and add an integration test
covering the effective PATH across subsequent action and shell steps on macOS
and Windows.

[eregon]

Since the selected Ruby is prepended, it should win command lookup without removing unrelated PATH state.

That works for ruby itself, and for gem, but not necessarily for bundle, rake, and other gem binaries that might exist in PATH before.

I think the initial motivation was to avoid mixing such executables from different directories, which would result in very confusing results/errors. (@MSP-Greg might recall better)
It's also I think pretty much discouraged in general to have 2 Ruby installations in PATH. It's sometimes unavoidable with a system Ruby in /usr/bin, but that's not the case for GitHub Actions.

If removal is required for a case that prepending does not handle, it would be
helpful to document why this split mutation is safe and add an integration test
covering the effective PATH across subsequent action and shell steps on macOS
and Windows.

PR welcome for that.
And yes, we tried various things (e.g. do everything through setting the ENV var), and it turned out setting the ENV var to remove + append to GITHUB_PATH worked best.
It's a little confusing in the GHA UI, but I'd argue that's something to improve on the GHA side, it's confusing to show a PATH which is not the real one.
Also note that even if we only set the env var and didn't touch GITHUB_PATH it'd still be confusing with other actions appending to GITHUB_PATH.

Also without an actual issue I'm not inclined to change this as it would carry pretty big risks.

[kjanat]

Thanks for explaining. I understand why prepending alone is insufficient: a command missing from the selected Ruby installation can still be found in an older installation later on PATH.

My original workflow did run the selected Ruby correctly. The misleading PATH shown in later step headers did not demonstrate a runtime failure.

I tested the cleanup further and found a separate limitation: entries previously added through GITHUB_PATH remain available after setup-ruby removes them from the PATH value exported through GITHUB_ENV.

This can happen with two setup-ruby calls in one job:

1. Set up Ruby 3.3 and install a gem that provides a command.
2. Set up Ruby 3.4.
3. Run ruby and the previously installed gem command.

The observed Ruby versions were:

ruby:        3.4.10
gem command: 3.3.12

This reproduced on Linux, macOS, and Windows. The same test folder was removed correctly when it had been added only through GITHUB_ENV.

Reproduction repository · Test run

That limitation does not support replacing the existing cleanup with prepend-only. I'll close the original request. The reproduction may still be useful for documenting the limitation and adding integration coverage.