`startsWith` (string) isn't appropriate for versions

[andreasabel]

actions/setup/src/opts.ts

Lines 97 to 99 in 1c618fb

	version === 'latest'
	? supported[0]
	: supported.find(v => v.startsWith(version)) ?? version;

Say the user requests stack-version: 2.1 this will atm resolve to 2.1.3, according to the action's current consciousness about versions:

actions/setup/src/versions.json

Lines 53 to 63 in 1c618fb

	"stack": [
	"2.9.3",
	"2.9.1",
	"2.7.5",
	"2.7.3",
	"2.7.1",
	"2.5.1",
	"2.3.3",
	"2.3.1",
	"2.1.3",
	"2.1.1",

However, once we add stack version 2.11.1, requesting 2.1 will resolve to 2.11.1. Ooops!

I suppose the proper ("Haskell") way to fix this to use a datatype for versions rather than mocking around with strings.

[sol]

Feel free to take inspiration from here: https://github.com/hspec/setup-haskell/blob/bdd4c910d94a07946cfdf9e6c3e7299a7e123705/src/resolve.ts#L8-L23

and here:
https://github.com/hspec/setup-haskell/blob/bdd4c910d94a07946cfdf9e6c3e7299a7e123705/src/resolve.ts#L25

[andreasabel]

@sol Thanks for the pointer! (Which makes me think why I am maintaining another setup action; maybe it is more general by allowing to pick a cabal or stack version, but I am not sure how useful this is; I do need the output cabal-store, though, how do you get the value of this in your workflows?)

You seem to have solved the same problems, and in a nice way; I was thinking of using the https://www.npmjs.com/package/compare-versions library for comparing versions, and maybe also its satisfies function, so that one could also write ghc-version: >= 9.4 etc.

[sol]

@sol Thanks for the pointer! (Which makes me think why I am maintaining another setup action; maybe it is more general by allowing to pick a cabal or stack version, but I am not sure how useful this is

It's possible to install what you need with ghcup directly (I think @hasufell has made this point elsewhere before).

The main reason why I rolled my own back then was that I needed old versions of GHC that need to be apt installed + that this was notoriously broken here.

That, and the fact that this repo includes multiple actions, which is broken in its own way (not only can't you publish anything to the marketplace, but it also makes it hard to version those actions independently).

the output cabal-store, though, how do you get the value of this in your workflows?

As of now, I do set it manually (https://github.com/sol/hpack/blob/21480fd93c0538bf010bff1bc6d6f9d2f19f8653/.github/workflows/build.yml#L51), which is not ideal.

so that one could also write ghc-version: >= 9.4

Given that the runner images already provide the latest version of GHC (which satisfies constraints of that form), I am puzzled when you would actually need something like this.

[hasufell]

Say the user requests stack-version: 2.1 this will atm resolve to 2.1.3

ghcup install stack 2.9 already works.

[andreasabel]

However, once we add stack version 2.11.1,

Sooner than expected, the calamity strikes us: https://discourse.haskell.org/t/ann-stack-2-11-1/6287

• https://github.com/commercialhaskell/stack/releases/tag/v2.11.1

Trying to add stack 2.11.1 breaks the internal testsuite.

    Expected: "2.1.3"
    Received: "2.11.1"

Great to have the testsuite!