search

benchkram / bob

Bob is a high-level build tool for multi-language projects.
https://bob.build
Apache License 2.0
466 stars 14 forks source link

nix-channel --update when building nix dependencies #130

Open zuzuleinen opened 2 years ago

zuzuleinen commented 2 years ago

Maybe we should run nix-channel --update before building dependencies with nix to make sure everyone has the latest local nixpkgs:

$ nix-channel --update

maybe a bob nix update cmd which does that?

This will not really solve the reproducibility issue. Maybe find a way to lock nixpkgs version. We have a way to use a certain version for nixpkgs but maybe is not that user friendly?

zuzuleinen commented 2 years ago

@Equanox @rdnt I think we need to prio "Maybe find a way to lock nixpkgs version. " in the context of launching the remote store.

Builds should use the same nixpkgs when building to assure reproducibility. If nixpkgs is not pinned to bob.yaml then is possible that an artifact pushed to a store can have different store paths than a machine which will pull that artifact from store.

rdnt commented 2 years ago

@zuzuleinen if nix-pkgs is not explicitly specified, the latest stable commit hash should be used, and embedded into the artifacts that are built, as if it was declared in the bobfile itself.

We should also consider what to do if a child bobfile has a different nixpkgs version across an aggregate. IMHO, if we do have to pick a version, we should use the oldest commit of nixpkgs across all the aggregated bobfiles.

rdnt commented 2 years ago

We should also consider handling 'stable' or 'unstable' (latest-stable / latest-unstable maybe?) value for nixpkgs to always use the latest variant. Finding the commit hash is manual work and the commit hash itself does not say if it's a stable or unstable version.

zuzuleinen commented 2 years ago

@zuzuleinen if nix-pkgs is not explicitly specified, the latest stable commit hash should be used, and embedded into the artifacts that are built, as if it was declared in the bobfile itself.

This still won't solve the reproducibility issue. Latest stable can change depending on the time a build is run

rdnt commented 2 years ago

@zuzuleinen if nixpkgs version is added as input to artifacts, then it is okay if future builds will use a more recent nixpkgs. Old artifacts will become stale and eventually be deleted.

zuzuleinen commented 2 years ago

@zuzuleinen if nixpkgs version is added as input to artifacts, then it is okay if future builds will use a more recent nixpkgs. Old artifacts will become stale and eventually be deleted.

Then in that case should be OK