-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/nix #34
base: main
Are you sure you want to change the base?
Feature/nix #34
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
949411c
to
fd70f97
Compare
@@ -39,6 +39,10 @@ runs: | |||
with: | |||
method: kubeconfig | |||
kubeconfig: ${{ inputs.QA_KUBECONFIG }} | |||
- name: Install Nix |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:
- Checkout the code
- install nix
- 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:
- Checkout the code
- setup-run-tests-environment action
- install nix
- 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.
Note: with this the |
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. |
No description provided.