Don't install ghc before restoring dependencies

[deemp]

GitHub runners currently use stack 2.13.1 (e.g., Ubuntu).

Currently, the action runs stack query compiler and downloads GHC before restoring the deps cache.

stack-action/action.yml

Lines 177 to 179 in ac0dd8d

	stack --no-terminal --stack-yaml ${{ inputs.stack-yaml }} \
	${{ steps.setup.outputs.resolver-nightly }} \
	query compiler | tee "$tmp"

stack-action/action.yml

Line 196 in ac0dd8d

- name: Restore dependencies cache

In stack 2.14.0, it became possible to run stack path without installing GHC (commercialhaskell/stack#6340).

To restore deps, the action runs stack path.

stack-action/action.yml

Lines 189 to 191 in ac0dd8d

	stack --no-terminal --stack-yaml ${{ inputs.stack-yaml }} \
	${{ steps.setup.outputs.resolver-nightly }} \
	path | while IFS=:\ read -r name value; do

When stack 2.14.0 (or newer) is available on runners, stack path won't install GHC.

Possibly, stack query compiler will still install GHC. If it's the case, this command should be run after the dependencies are restored, so that this command doesn't install a GHC.

[pbrisbin]

Thanks for the report.

This seems pretty annoying to work around (though PRs welcome), so I'm optimistic it'll Just Work with 2.14 and would prefer to check that before doing anything. I think if we tossed a stack update in our own CI, that should get 2.14 and we could see how it works?

[deemp]

Sorry for the delayed response.

I think there will be 2.15 (commercialhaskell/stack#6397).

It's not currently available, but I think it's possible to build stack from source in its repo if you'd like to experiment.

[pbrisbin]

Since this has been an issue since the get-go, I'm comfortable leaving it open for a while longer till it's easier to experiment (e.g. until a stack update will get 2.15).

[pbrisbin]

I've dug into this a little more now that 2.15 is available.

It seems that stack path --stack-root specifically no longer requires a GHC install to run. But a bare stack path or stack path --most-other-things will still install GHC.

In order to restore a cache, we need to know the paths and key. Right now that means:

• stack path --stack-root
• stack path --programs
• stack query compiler to include the compiler in the cache key

To avoid doing any of this before we've restored a cache, we can:

• Rely on stack 2.15 for stack path --stack-root to not install GHC
• Use "stack.yaml"[resolver] for that part of the cache key, instead of calling stack query compiler early
• Move calling stack path and/or stack query compiler for the purposes of setting outputs back to the end of the action

That just leaves stack path --programs.

On my system (Linux) this returns a directory that is under ~/.stack. That means there is no reason to include it as its own cache path, it will be included by caching ~/.stack already. However, it was added when we were working on Windows caching stuff, so I worry it returns a path outside of ~/.stack on Windows.

@deemp can you check that? If it does... is it worth calling stack path --programs (and so installing GHC, etc) before we restore a cache? Is there any other way we can find this path?

[deemp]

Yes, newer stack path --programs downloads GHC.

I think the easiest solution is to create an issue and ask to not download GHC for stack path --programs (and possibly for some other options). If you agree, could you please do that?

Here's why (not sure whether it's correct).

As I understand, there's config.yaml with global settings (link).

If the file is deleted, and Stack needs to consult it, Stack will create a file with default contents.

link

Stack obtains global configuration from a file named config.yaml.

It's possible to configure stack path --programs via local-programs-path (link). The paths are different on Linux and Windows.

The local-programs-path belongs to non-project-specific configuration (link).

Non-project configuration options can be included in a project-level configuration file (stack.yaml) or in global configuration files (config.yaml).

So, to determine the output of stack path --programs, we'll need to consult several config files in the same way stack does it.

[pbrisbin]

As I understand, there's config.yaml with global settings

Well, we can ignore (~/.stack/)config.yaml because that is local to a users machine, and is not part of the cloned project on a GitHub Runner -- I seriously doubt GitHub is using the file to adjust anything on their runners, right?

The local-programs-path belongs to non-project-specific configuration

We could (easily) just look at stack.yaml ourselves for local-programs-path. In the TypeScript branch I'm working on I already have the code to decode the Yaml and could add whatever keys we're interested in.

The only real downside is we will be duplicating the knowledge of what the default is when the key is not specified:

Linux: {caching stack-root includes it}

Windows: %LOCALAPPDATA%\Programs\stack, if the %LOCALAPPDATA% environment variable exists. Otherwise, {caching stack-root includes it}

The windows logic is a bit annoying, but I think that's kind of worth it to do now, even if we report a Stack Issue, rather than waiting for them.

WDYT?

[pbrisbin]

Good news! It seems stack path --programs doesn't, in fact, install GHC:

So we should be good. I also see that v2.15 is already the version of stack on the GitHub runners now. So once the TypeScript branch is merged, this Issue will be addressed.

EDIT: hang on. I might've spoke too soon. Let me test another thing.

[deemp]

I think that's kind of worth it to do now

I agree. We seem to have no other options until new versions of stack are available on runners.

I regret a bit that I thought their fix covered more options than only --stack-root. I could have created an issue about stack path before the release of stack 2.15. Anyway, now there is an issue in the stack repo.

[deemp]

Good news! It seems stack path --programs doesn't, in fact, install GHC:

After I had removed ~/.stack, it decided to download GHC.

[pbrisbin]

Yeah, I think I just misread the output. Alright, we'll I'll re-implement the logic for now and we can go back to stack path if/when it's addressed, again.

[deemp]

Well, we can ignore (~/.stack/)config.yaml because that is local to a users machine

Well, a user may write a custom file, but probably it's a rare case.

[deemp]

Yeah, I think I just misread the output.

Perhaps you know that https://github.com/mxschmitt/action-tmate allows to connect to a runner. So, you can execute some commands manually to inspect what's going on.

[pbrisbin]

That's neat!

[deemp]

The new stack should be available in "a few weeks" (link).

[pbrisbin]

This is now addressed. We are coding our own logic for stack path --programs, and will want to switch that when a fixed Stack is released, but we are not installing GHC ahead of caching anymore.