Feature/nix

[krebernisak]

No description provided.

[tateexon]

This kind of conflicts with how this setup uses asdf for versions. For example if the project has a version for golang in asdf .tool-versions and has a different version in nix then we end up installing golang twice. Also how does this nix install behave for all the projects this is used in that do not have nix?

[tateexon]

Since nix is non standard we need to add a bool input for whether we use it or not and default it to false. This might not be the best way to do this though, we may want to add a bool to the run-test action to run the setup, this would allow you to use the setup action or the nix install or both in whatever order you need before the run-test action in your workflow.

[krebernisak]

Why wouldn't we adopt Nix as standard?

It's been working for us almost seamlessly, across integrations, but that's because we have @archseer who has Nix experience. He can comment on any potential toolchain conflicts. I also encourage him to start sharing his Nix knowledge more, so we can adopt it more broadly.

The implementation in this PR works for our use case: smartcontractkit/chainlink-starknet#102

Now what is the exact problem... We have this test-runner machine that the GH action spins up. It installs Go + k8s and expects the full e2e tests to run with only bash, Go and k8s. What if a developer needs something else to prepare the tests? Let's say it needs Rust, or it needs Cairo for our StarkNet use case.

The only current option is for the developer to define its environment as a Helm chart and spin that up in k8s to do the required setup (compile and deploy contracts, for example). This is a great option, but it's involved and potentially not enough if the developer really needs/wants to use the host machine for whatever reason. This is why I think Nix is a great addition and another option for the developer to define his environment and the toolchain.

[tateexon]

The root of the problem is that you are injecting nix into the setup. These actions setup what is needed to run tests, not your specific environment. Because these are actions you can run nix before these actions if you have further setup for your environment or for whatever commands get ran in the setup and test run. For example your workflow can have steps in this order:

1. Checkout the code
2. install nix
3. run-tests action (which also does the setup for the tests)

If you need the nix install to happen after the setup in run tests we can add a boolean so you can run your steps in this order:

1. Checkout the code
2. setup-run-tests-environment action
3. install nix
4. run-tests action

With how you are currently adding nix in this PR it would be no different than the first option which means you wouldn't have to make this PR at all.

[archseer]

Note: with this the tool-versions code to set up the correct go version also becomes obsolete since we can just use the Nix environment for that

[tateexon]

Note: with this the tool-versions code to set up the correct go version also becomes obsolete since we can just use the Nix environment for that

I will add a task to get nix added to this properly. I think it needs to be placed in the setup and not the runner with the ability to use nix or the old until more people are trained on nix and more projects having working nix files for test.