Closed ipetkov closed 1 year ago
Not sure about allowing/evaluating more than 1 (arbitrarily named) top-level flake output attr. We can change the schema to support multiple configs, at the cost of breaking backwards compatibility (which I'm fine with):
{
outputs = _: {
nixci = {
default = { ... };
alt-config = { ... };
};
};
}
Then, nixci .
will use the "default" config, and nixci .#alt-config
(for example) would use the other config. This structure is similar to packages, devShells, checks, too.
Wonder if there are other ways of solving your use case ...
Something to think about: are there other requirements that will affect our decision regarding the new config schema? For example, #2.
A schema change might be the best way forward if it's in the cards, this was a simpler attempt to avoid introducing actual breaking changes!
A schema change might be the best way forward if it's in the cards
Yup, let's go with that. I want to release 0.2 with this change.
Sounds good! Will close this as it's not going in the desired direction
This allows invoking
nixci .#alt-config
which will evalute thealt-config
attribute in the current flake. If not specified, it will fallback to usingnixci
as a default for backwards compatible behavior.This is useful for situations where one might want to split up their
nixci
configs. For example, I have a project with a very large test suite (tests on both nixpkgs-unstable, as well as the latest release) and building all subflakes in one go makes the Github Action runners run out of disk space. But with this feature I can split up my configs in to separate "runs"