More CI speed #1626
More CI speed #1626
Conversation
| @@ -268,7 +268,28 @@ | |||
| # Build *just* the cargo dependencies, so we can reuse all of that work (e.g. via cachix) when running in CI | |||
| cargoArtifacts = craneLib.buildDepsOnly { | |||
| inherit pname src; | |||
| cargoExtraArgs = "${cargoBuildExtraArgs} --workspace --all-features"; | |||
| cargoExtraArgs = "${cargoBuildExtraArgs} --all-features"; | |||
There was a problem hiding this comment.
Should we keep all features here? Or keep it but make sure that the subsequent buildPackage also have all-features? From our last discussion I had the impression that what we want is that the features set used to build the packages should be - as much as possible - the same feature set as the one used in cargoArtifacts. In fact I think on the CI we should probably always enable all features by default (the best would be to test different feature sets, but if we have to chose one feature set, all-features is probably the one with the maximal covering)
There was a problem hiding this comment.
It's only an issue if we have upstream dependencies whose feature sets depends on the set of features enabled on our crates. At the moment, we don't have any such situations, but in theory it could come up in the future. My impulse is to deal with it if/when it comes up, but the downside of that is that nobody will notice anything is wrong, CI will just silently start taking a little longer.
| ( | ||
| cd $packageDir | ||
| pwd | ||
| cargoWithProfile $command "$@" |
There was a problem hiding this comment.
Where's cargoWithProfile defined?
There was a problem hiding this comment.
somewhere in craneLib. it's the default value of cargo{Build,Test,Check}Command
nickelWasmto release build so it hits the cachecargoArtifactsderivation, so that when we build them separately later they hit the cache correctly--workspaceand--package foobuild dependencies with different features (cache miss) ipetkov/crane#396