lix-releng-staging/tests/dyn-drv/local.mk

dyn-drv-tests := \
  $(d)/text-hashed-output.sh \
  $(d)/recursive-mod-json.sh \
  $(d)/build-built-drv.sh \
  $(d)/eval-outputOf.sh \
  $(d)/dep-built-drv.sh

install-tests-groups += dyn-drv

clean-files += \
  $(d)/config.nix

test-deps += \
  tests/dyn-drv/config.nix
Introduce notion of a test group, use for CA tests Grouping our tests should make it easier to understand the intent than one long poorly-arranged list. It also is convenient for running just the tests for a specific component when working on that component. We need at least one test group so this isn't dead code; I decided to collect the tests for the `ca-derivations` and `dynamic-derivations` experimental features in groups. Do ```bash make ca.test-group -jN ``` and ```bash make dyn-drv.test-group -jN ``` to try running just them. I originally did this as part of #8397 for being able to just the local overlay store alone. I am PRing it separately now so we can separate general infra from new features. Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io> 2023-07-10 02:24:51 +00:00			`dyn-drv-tests := \`
			`$(d)/text-hashed-output.sh \`
Make the Derived Path family of types inductive for dynamic derivations We want to be able to write down `foo.drv^bar.drv^baz`: `foo.drv^bar.drv` is the dynamic derivation (since it is itself a derivation output, `bar.drv` from `foo.drv`). To that end, we create `Single{Derivation,BuiltPath}` types, that are very similar except instead of having multiple outputs (in a set or map), they have a single one. This is for everything to the left of the rightmost `^`. `NixStringContextElem` has an analogous change, and now can reuse `SingleDerivedPath` at the top level. In fact, if we ever get rid of `DrvDeep`, `NixStringContextElem` could be replaced with `SingleDerivedPath` entirely! Important note: some JSON formats have changed. We already can produce dynamic derivations, but we can't refer to them directly. Today, we can merely express building or example at the top imperatively over time by building `foo.drv^bar.drv`, and then with a second nix invocation doing `<result-from-first>^baz`, but this is not declarative. The ethos of Nix of being able to write down the full plan everything you want to do, and then execute than plan with a single command, and for that we need the new inductive form of these types. Co-authored-by: Robert Hensing <roberth@users.noreply.github.com> Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io> 2023-01-15 22:39:04 +00:00			`$(d)/recursive-mod-json.sh \`
Create `outputOf` primop. In the Nix language, given a drv path, we should be able to construct another string referencing to one of its output. We can do this today with `(import drvPath).output`, but this only works for derivations we already have. With dynamic derivations, however, that doesn't work well because the `drvPath` isn't yet built: importing it like would need to trigger IFD, when the whole point of this feature is to do "dynamic build graph" without IFD! Instead, what we want to do is create a placeholder value with the right string context to refer to the output of the as-yet unbuilt derivation. A new primop in the language, analogous to `builtins.placeholder` can be used to create one. This will achieve all the right properties. The placeholder machinery also will match out the `outPath` attribute for CA derivations works. In 60b7121d2c6d4322b7c2e8e7acfec7b701b2d3a1 we added that type of placeholder, and the derived path and string holder changes necessary to support it. Then in the previous commit we cleaned up the code (inspiration finally hit me!) to deduplicate the code and expose exactly what we need. Now, we can wire up the primop trivally! Part of RFC 92: dynamic derivations (tracking issue #6316) Co-authored-by: Robert Hensing <roberth@users.noreply.github.com> 2021-03-10 04:22:56 +00:00			`$(d)/build-built-drv.sh \`
			`$(d)/eval-outputOf.sh \`
			`$(d)/dep-built-drv.sh`
Introduce notion of a test group, use for CA tests Grouping our tests should make it easier to understand the intent than one long poorly-arranged list. It also is convenient for running just the tests for a specific component when working on that component. We need at least one test group so this isn't dead code; I decided to collect the tests for the `ca-derivations` and `dynamic-derivations` experimental features in groups. Do ```bash make ca.test-group -jN ``` and ```bash make dyn-drv.test-group -jN ``` to try running just them. I originally did this as part of #8397 for being able to just the local overlay store alone. I am PRing it separately now so we can separate general infra from new features. Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io> 2023-07-10 02:24:51 +00:00
			`install-tests-groups += dyn-drv`

			`clean-files += \`
			`$(d)/config.nix`

			`test-deps += \`
			`tests/dyn-drv/config.nix`