serokell / deploy-rs

A simple multi-profile Nix-flake deploy tool.
Other
1.41k stars 101 forks source link

[#202] Provide '^out' suffix for deriver on newer nix #203

Closed rvem closed 1 year ago

rvem commented 1 year ago

Problem: Since 2.15 nix no longer reference '.drv' as derivation outputs. At the same time, nix before '2.13' doesn't support '.drv' special suffix handling.

Solution: Provide '^out' suffix for the profile deriver in case 'nix path-info <...>.drv' returns the same '<...>.drv' path. In other cases either an error about the build result not being present in the /nix/store is returned or an actual build result path is returned.

Resolves #202

dschrempf commented 1 year ago

I can confirm that deployment works with this branch and Nix 2.15.

EDIT: One weird thing I noticed (may not be the fault of deploy-rs); have a look at the file sizes :smile: : image

soupglasses commented 1 year ago

I can also confirm this works correctly. However, it will not use substitutes that you have set up yourself in extra-substituters. So you will be building everything that would otherwise have been substituted.

Using nix build .#nixosConfigurations.nona.config.system.build.toplevel will pull from my substituter, so this is an issue of how deploy-rs is pulling from the cache with nix 2.15.0.

rvem commented 1 year ago

Hmm, that's unexpected, I'll take a look on why these derivations diverge

rvem commented 1 year ago

so this is an issue of how deploy-rs is pulling from the cache with nix 2.15.0.

I believe that nothing has really changed on the deploy-rs side, deploy.nodes.<node>.profiles.system.path uses the corresponding nixosConfiguration as input and thus it should be fetched from cache :thinking:

Tried locally as well. deploy .#<node> fetched from the cache instead of building the profile from scratch

soupglasses commented 1 year ago

An interesting point I noticed was that after using nix build to fetch from my personal cache, the deploy command would happily use the derivations that had been downloaded.

I will try to see if the derivations change if I let deploy-rs build it.

soupglasses commented 1 year ago

Just got some time. Both derivations end up as the same hash. So there is something about deploy-rs where it does not realize that there exists a cache in nixConfig.extra-substituters from the flake.nix file with that package when using nix 2.15.0 and the current PR here.

# nix build - was downloaded from cache
/nix/store/2lyxfjv87kvcns16rs439n5idak5p71c-jellyfin-10.8.8
/nix/store/24ml78h7i7h7a384bhnf00ansakq4zvv-jellyfin-web-10.8.8

# deploy-rs - was built from source
/nix/store/2lyxfjv87kvcns16rs439n5idak5p71c-jellyfin-10.8.8
/nix/store/24ml78h7i7h7a384bhnf00ansakq4zvv-jellyfin-web-10.8.8
rvem commented 1 year ago

Can you check if this behaviour also happens for nix before 2.15.0 and deploy-rs before this PR?

soupglasses commented 1 year ago

You are indeed correct. This actually happens on nix 2.14.1 as well. Now i am unsure how i have not noticed this before.

dschrempf commented 1 year ago

That's funny because I just have installed the same package on my server with deploy-rs and it definitely fetched the package from cache.

EDIT: No, actually it was vvvfj076kgxbgr96qdqa71sj77g9hv3l-jellyfin-10.8.9/.

soupglasses commented 1 year ago

@dschrempf Yeah i am running my own custom patchset of jellyfin, which is why i am using it as an example. I should have specified that it was not the nixpkgs jellyfin.

rvem commented 1 year ago

@imsofi, I slightly changed the approach, can you check if the new version still works as expected for you?

soupglasses commented 1 year ago

Seems to work fine :+1:

Had a one off error: failed to start SSH connection to 'user@hostname' that i have never seen before. But rerunning the command worked correctly. Unsure if that indicates anything or if my server just decided to be wonky this one time.

PhilTaken commented 1 year ago

error: failed to start SSH connection to 'user@hostname'

that doesn't seem to be related to this pr (fingers crossed) but seems worth investigating if the issue can be reproduced

soupglasses commented 1 year ago

Never seen it since. So it's likely just a badly placed connection issue just as I tested the new version of the PR 😅