Implement hs-bin@repl test as go bazel test

[k1nkreet]

According to #951 this PR makes a first step to implement integration tests as go_bazel_test from rules_go

[aherrmann]

I think you could reuse this config_setting based on the support_nix platform constraint. Then you also don't need to introduce the --define=nixpkgs above.

[k1nkreet]

Thanks! Fixed

[k1nkreet]

According to last ci task on Windows there is no bazel binary in PATH occurred inside bazel test, so it probably makes sense to implement an external dependency of integration_test rule on bazel binary within this PR

[k1nkreet]

All CI tests are finally passed but I have a strong feeling that using tmp filesystem for bazel cache inside integration tests is not a good idea. Cache size will constantly grow and tmpfs on average machine is pretty limited. I've already experienced freezing of my laptop sometimes when I'm running these tests. So I will try to find another place writable by bazel tests and invariant between tests

[k1nkreet]

For basic rules_haskell's integration Bazel test creates about 800MB of cache. It nearly exceeds size of $TMPDIR folder created by Nix on my machine for example but fits /tmp without any problem. So I see two ways to store cache of internal bazel:

• Use golang os.TempDir() to pass it as $HOME for test: it uses $TMPDIR on Unix system and %TEMP% on Windows. In this case we'll need to add TMPDIR=/tmp as shellHook in shell.nix for nixpkgs configurations. Also Bazel cache will stuck in /tmp after tests run which concerns me a bit.
• Pass $HOME through the --action_env: it will share cache between external and internal Bazel which probably could even speed up things sometimes but also breaks sandboxing of tests a bit more. Also it could affect sandboxing of other tests since they all will have non-sandboxed $HOME. Also it worth mentioning go_bazel_tests in rules_go just use common $HOME but would break with strict action_env.

I'm leaning towards the first option, @aherrmann do you have an opinion?

[aherrmann]

I'm leaning towards the first option, @aherrmann do you have an opinion?

Yes, the first option seems preferable. I'd prefer to avoid the need for --action_env because it would affect all targets and impact their cache keys.

[k1nkreet]

@aherrmann It's finally ready for being reviewed :)

[aherrmann]

🎉 Good work, thank you!
A couple comments/questions.

[aherrmann]

This is great, thank you!
I've tested it locally and tests work as expected with and without Nix.