Attemps to download .exe version for Linux when Node version not found in cache

[domdomegg]

Description:
When a node version is not found in the cache, for example when using 'current' or '19.8.1' at the moment, it appears that the action tries to download the .exe version despite running on a linux system.

Action version:
Specify the action version

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Tools version:
node: 'current' (resolved to v19.8.1)
package manager: npm

Repro steps:

GitHub workflow:

name: Repro
on: push
jobs:
  repro:
    runs-on: ubuntu-latest
    steps:
      - name: Use Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '19.8.1'

Expected behavior:
The action downloads the binaries from the node site.

Actual behavior:
The action attempts to download the .exe version, which fails.

Example logs:
https://github.com/domdomegg/typescript-library-template/actions/runs/4430005745/jobs/7771191230

getting latest node version...
Attempting to download v19.8.1...
Not found in manifest. Falling back to download directly from Node
Acquiring 19.8.1 - x64 from https://nodejs.org/dist/v19.8.1/node-v19.8.1-linux-x64.tar.gz
Downloading only node binary from https://nodejs.org/dist/v19.8.1/win-x64/node.exe
Error: Unexpected HTTP response: 404

[domdomegg]

The issue appears to stem from:

setup-node/src/distributions/base-distribution.ts

Lines 154 to 197 in a4fcaaf

	protected async acquireNodeFromFallbackLocation(
	version: string,
	arch: string = os.arch()
	): Promise<string> {
	const initialUrl = this.getDistributionUrl();
	const osArch: string = this.translateArchToDistUrl(arch);
	// Create temporary folder to download in to
	const tempDownloadFolder: string =
	'temp_' + Math.floor(Math.random() * 2000000000);
	const tempDirectory = process.env['RUNNER_TEMP'] || '';
	assert.ok(tempDirectory, 'Expected RUNNER_TEMP to be defined');
	const tempDir: string = path.join(tempDirectory, tempDownloadFolder);
	await io.mkdirP(tempDir);
	let exeUrl: string;
	let libUrl: string;
	try {
	exeUrl = `${initialUrl}/v${version}/win-${osArch}/node.exe`;
	libUrl = `${initialUrl}/v${version}/win-${osArch}/node.lib`;
	core.info(`Downloading only node binary from ${exeUrl}`);
	const exePath = await tc.downloadTool(exeUrl);
	await io.cp(exePath, path.join(tempDir, 'node.exe'));
	const libPath = await tc.downloadTool(libUrl);
	await io.cp(libPath, path.join(tempDir, 'node.lib'));
	} catch (err) {
	if (err instanceof tc.HTTPError && err.httpStatusCode == 404) {
	exeUrl = `${initialUrl}/v${version}/node.exe`;
	libUrl = `${initialUrl}/v${version}/node.lib`;
	const exePath = await tc.downloadTool(exeUrl);
	await io.cp(exePath, path.join(tempDir, 'node.exe'));
	const libPath = await tc.downloadTool(libUrl);
	await io.cp(libPath, path.join(tempDir, 'node.lib'));
	} else {
	throw err;
	}
	}
	const toolPath = await tc.cacheDir(tempDir, 'node', version, arch);
	return toolPath;
	}

[domdomegg]

What's odd is that the logs would suggest it identified the right URL first time. And the code suggest it tried this but got a 404. However, that link seems to work when I try to hit it myself. So I'm quite uncertain why this is happening - maybe there's some odd caching going on given the version was released recently, and the action runners are hitting a different cache than me. But setup-node should handle this gracefully.

[domdomegg]

After thinking more about this, there appear to be two bugs here:

1. When things fail, we fallback to downloading windows binaries even when not on windows.
2. Things fail due to caching errors on nodejs.org, where https://nodejs.org/dist/index.json says a version exists but the binaries are unavailable.

For clarity, this issue is dealing solely with issue 1.

I've created a separate issue, #717, for 2.

[dmitry-shibanov]

Hello @domdomegg. Thank you for your report. We'll investigate the issue.

[BorisTacyniak]

Hello @dmitry-shibanov

This issue is blocking pipelines, do you have an ETA on the investigation ?