If coder is installed via winget, local binary fallback fails because plugin expects release artifact name instead of installed executable name

[dvanwissen]

When Coder is installed on Windows via winget, the installed executable is named coder.exe.
However, the binary lookup logic currently resolves the filename using getCoderCLIForOS(), which returns the downloadable release artifact name such as coder-windows-amd64.exe.

As a result, the plugin does not find the CLI when it is installed through winget and the binary directory is set via setings.

---

installed/local CLI lookup on Windows using winget should look for coder.exe
auto-install via jetbrains tooling may still use coder-windows-amd64.exe

It should not only be able to use the downloaded binary via the coder server, but also pre-installed coder binaries already available.

Code:

jetbrains-coder/src/main/kotlin/com/coder/gateway/settings/CoderSettings.kt

Lines 423 to 444 in 4233ee7

	private fun getCoderCLIForOS(os: OS?, arch: Arch?): String {
	logger.debug("Resolving binary for $os $arch")
	val (osName, extension) = when (os) {
	OS.WINDOWS -> "windows" to ".exe"
	OS.LINUX -> "linux" to ""
	OS.MAC -> "darwin" to ""
	null -> {
	logger.error("Could not resolve client OS and architecture, defaulting to WINDOWS AMD64")
	return "coder-windows-amd64.exe"
	}
	}
	val archName = when (arch) {
	Arch.AMD64 -> "amd64"
	Arch.ARM64 -> "arm64"
	Arch.ARMV7 -> "armv7"
	else -> "amd64" // default fallback
	}
	return "coder-$osName-$archName$extension"
	}

Tests:

jetbrains-coder/src/test/kotlin/com/coder/gateway/settings/CoderSettingsTest.kt

Lines 464 to 476 in 4233ee7

	private fun assertBinaryAndSignature(
	osName: String?,
	arch: String?,
	expectedBinary: String,
	expectedSignature: String
	) {
	if (osName == null) System.clearProperty("os.name") else System.setProperty("os.name", osName)
	if (arch == null) System.clearProperty("os.arch") else System.setProperty("os.arch", arch)
	Assertions.assertEquals(expectedBinary, store.defaultCliBinaryNameByOsAndArch)
	Assertions.assertEquals(expectedSignature, store.defaultSignatureNameByOsAndArch)
	}

[fioan89]

Thank you @dvanwissen for reporting this issue. I took a look over this issue I'm not able to reproduce. The CLI directory is the place where the plugin will download the CLI from the deployment. Below is a screenshot of my setting. Can you maybe share a screenshot with your settings? Also, Gateway is deprecated by JetBrains with the recommendation to use JetBrains Toolbox. Coder provides similar support.

[dvanwissen]

@fioan89 Thank you for the reply and trying to reproduce my intentions. The issue is that in a situation in which the user has no administrative rights and is not able to choose which binaries may be run, not all locations may be available to be used for executing programs. The locations that are eligible are not writable by non-administrative users and binaries with executable permissions are subject to a signature check.

If the installation of the client is not automated using the Gateway or JetBrains Toolbox by using the client binary received from the server installation, but manually using the winget CLI tool, the binary has the name coder.exe. When I set the location of coder to the directory the winget CLI tool installed it in (which currently defaults to C:\Program Files (x86)\WinGet\Packages\Coder.Coder_Microsoft.Winget.Source_*. The Coder tool within JetBrains uses the given directory in the CLI directory input field to search for the binary with the name coder-windows-amd64.exe which does not exist in this situation. If I would rename the binary to the name it's looking for, it seems to work as intended. But in my opinion, the name of the binary should be included in the custom CLI location binding instead of only the name of the directory it resides in.

[fioan89]

Oh I see, it is more clear now - thx. I'm thinking that maybe it makes a lot more sense for the CLI source setting to be able to also cope with local CLI binaries instead. You can then provide an absolute file path to the executable, with no need to follow any convention. Also, Toolbox support is a priority since Gateway support is mostly deprected by JetBrains (and implicitly by Coder).

Is it possible for you to migrate to JetBrains Toolbox where we have a Coder Toolbox plugin similar to the Gateway? I'm hoping a fix for this issue to hit the marketplace this week, for Coder Toolbox.

[dvanwissen]

Thats great, good to hear! Just so you know, the JetBrains Toolbox has the same issue. Is there another location where I should create an issue for the Toolbox?

[fioan89]

I've already cloned coder/coder-jetbrains-toolbox#285 and PR is in progress.