We do this by introducing `flake_with_sops` fixture, that calls the
init method ahead of the test. We did not want to do this in the `flake`
fixture since not all tests using the `flake` fixture need to have sops
setup.
Change `prompt.persist` default to false.
We want a consistent default that is not conditionally dependent on
other values.
This makes communication on how the functionality is used more
consistent and easier understood.
- generate a flake.lock file for each template by copying the clan-core flake.lock and modifying it
- call nix build with --store for tests inside the sandbox
This adds options `invalidationData` to generators.
`invalidationData` can be used by an author of a generator to signal if a re-generation is required after updating the logic.
Whenever a generator with invalidation data is executed, a hash of that data is stored by the respective public and/or secret backends.
The stored hashes will be checked on future deployments, and a re-generation is triggered whenever a hash doesn't match what's defined in nix.
- deprecate fixture generate_flake in favor of class ClanFlake
- allow creating flake templates that can be copied, including their state, like git and lock files, in order to avoid expensive re-initialization
When the users of a secret change, when for example a new admin user is added, an error will be thrown when generating vars, prompting the user to pass --fix to re-encrypt the secrets
Prior to this, when initializing new machines, only the current user had access to it's key which prevents other admin users to deploy this machine later
- generate keys in ./sops instead of ./sops/vars for now
- don't initialize all flakes with sops keys, only generate when needed
- use the new 'clan vars keygen' in tests
When a second machine checks for a shared secret, now the exists() call returns negative and only when updating the secrets for that machine, the machine is added to the sops receivers.
Also throw proper errors when the user switches backends without cleaning the files first.
Migrating generated files from the facts subsystem to the vars subsystem is now possible.
HowTo:
1. declare `clan.core.vars.generators.<generator>.migrateFact = my_service` where `my_service` refers to a service from `clan.core.facts.services`
2. run `clan vers generate your_machine` or `clan machines update your_machine`
Vars will only be migrated for a generator if:
1. The facts service specified via `migrateFact` does exist
2. None of the vars to generate exist yet
3. All public var names exist in the public facts store
4. All secret var names exist in the secret fact store
If the migration is deemed possible, the generator script will not be executed. Instead the files from the public or secret facts store are read and stored into the corresponding vars store
