-
Notifications
You must be signed in to change notification settings - Fork 3
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
Run latest upstream master instead of pinning to a known-good version #38
Conversation
ad91aa0
to
fa9c99f
Compare
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.
I would not do this as it would breaks the reproducibility offered by Nix (I'm even surprised it is actually possible).
I would rather propose to handle this dependency as an input of the flake which is about to land in this repository (#33). And then automate the nix flake update
to bump this input on regular basis.
But I might be wrong.
The system runs on auto-update and installs whatever gets into the 'stable' channel anyway - why shouldn't we do that with our own software? |
l was naively thinking we were using NixOS to have some reproducibility when deploying environments. Does this means the |
I'd like the test grid to always be running the latest Tahoe-LAFS If flakes make that impossible, then I would please not have them. Maybe we have a different understanding of what the test grid or this repo is for? |
Let's talk about what you imagine this repository to look like when we're done vs. how I imagine it would look like. |
From the roadmap, the idea was:
But we've also stated that this was a WiP. So let's not flake it then. |
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.
If we do not want or can not have deployment reproducibility, then why not.
This is the test grid and we like to tun whatever is most current :)