Skip to content
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

Merged
merged 5 commits into from
Feb 26, 2025

Conversation

hacklschorsch
Copy link
Member

This is the test grid and we like to tun whatever is most current :)

@hacklschorsch hacklschorsch requested a review from btlogy February 17, 2025 11:40
@hacklschorsch hacklschorsch self-assigned this Feb 17, 2025
Copy link
Member

@btlogy btlogy left a 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.

@hacklschorsch
Copy link
Member Author

hacklschorsch commented Feb 19, 2025

I would not do this as it would breaks the reproducibility offered by Nix (I'm even surprised it is actually possible).

Nix isn't reproducible.

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.

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?

@btlogy
Copy link
Member

btlogy commented Feb 19, 2025

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.
If was wrong, forget it then.

Does this means the nixosConfiguration of testgrid should not end up build and deployed from the flake we're working on?

@hacklschorsch
Copy link
Member Author

l was naively thinking we were using NixOS to have some reproducibility when deploying environments.

I'd like the test grid to always be running the latest Tahoe-LAFS master branch.

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?

@hacklschorsch
Copy link
Member Author

Let's talk about what you imagine this repository to look like when we're done vs. how I imagine it would look like.

@btlogy
Copy link
Member

btlogy commented Feb 20, 2025

l was naively thinking we were using NixOS to have some reproducibility when deploying environments.

I'd like the test grid to always be running the latest Tahoe-LAFS master branch.

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?

From the roadmap, the idea was:

Refactor the Nix code to integrate the nixosConfiguration (of testgrid) with the top-level flake, which will be used to manage and automated the deployment of all NixOS configurations

But we've also stated that this was a WiP. So let's not flake it then.

Copy link
Member

@btlogy btlogy left a 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.

@hacklschorsch hacklschorsch merged commit 913720c into main Feb 26, 2025
@hacklschorsch hacklschorsch deleted the run-latest-upstream branch February 26, 2025 12:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants