Expose GHCup binary location as action output

[fendor]

vscode-haskell needs direct access to ghcup to run its test successfully. Until recently, ghcup was always on $PATH and we could simply run ghcup install ... and install all the binaries that we needed. Additionally, the tests themselves also call ghcup install.

However, this seems to have changed recently for macos-latest: https://github.com/haskell/vscode-haskell/actions/runs/9015398738/job/24769933756?pr=1077

It looks like ghcup is not on the $PATH any more, but hidden somewhere in the hostedtoolcache.

One way to work around this for good, is to provide the path to ghcup as an action output, then we don't have to rely on ghcup to be on the $PATH, and can find it reliably.

[fendor]

I see this seems to have been discussed at actions/runner-images#9242

[andreasabel]

@fendor wrote:

One way to work around this for good, is to provide the path to ghcup as an action output,

The logic to find ghcup is currently this one:

setup/src/installer.ts

Lines 334 to 353 in 64f55f9

	async function ghcupBin(os: OS, arch: Arch): Promise<string> {
	core.debug(`ghcupBin : ${os}`);
	if (os === 'win32') {
	return 'ghcup';
	}
	const cachedBin = tc.find('ghcup', ghcup_version);
	if (cachedBin) return join(cachedBin, 'ghcup');
	const binArch = await stackArchString(arch);
	const bin = await tc.downloadTool(
	`https://downloads.haskell.org/ghcup/${ghcup_version}/${binArch}-${
	os === 'darwin' ? 'apple-darwin' : 'linux'
	}-ghcup-${ghcup_version}`
	);
	await afs.chmod(bin, 0o755);
	return join(
	await tc.cacheFile(bin, 'ghcup', 'ghcup', ghcup_version),
	'ghcup'
	);
	}

It would be easy to export the string to invoke GHCup from this. Note however that it is not always the path to ghcup, e.g. for windows it will just be ghcup.
So the output could be named ghcup-command, for instance.
I do not know if this is sufficient for your purposes, please let me know.
It would be nicer to always return the path to ghcup, maybe as output ghcup-binary (to be bikeshedded), but this would require some more work (which I personally would not invest at this point).

I'd be happy to accept a PR with mild changes to the code base. (My main concern is backward compatibility.)

[fendor]

Your suggestion seems reasonable to me, and I think it would fix my issues nicely.