This fixes an issue where check_vars() would add machine keys or authorize machines for shared vars.
These write operations should only ever be done on a `clan vars generate`, which `clan vars check` should be a read-only operation
This should make it simpler to improve the implementation of granting a new machine access to a shared secret.
The current approach using the health_check is pretty hacky
When generators are shared between machines, their definition has to be the same across all machines. If not, it might lead to unexpected problems, as the architecture assumes that all definitions are the same.
fixes https://git.clan.lol/clan/clan-core/issues/5253
This improves the performance of deployment, by aggregating uncached select calls for vars generate into two batches.
batch 1: Get all generators of all machines
batch 2: get all final scripts for generators which need to run
Resolves the "RuntimeError: generator didn't stop after throw()" issue
by replacing the generator-based @contextmanager with an explicit class.
This maintains backward compatibility through a factory function.
This is preparational work to reduce the surface are of the different mappings
We want to reduce the following:
/guides/secrets.md -> Guides/getting started/How to use flakes with sops -> with '# Secrets Management'
- Title
- URI
- Filepath
should follow a stricter pattern to make it easy to maintain
optimize the `clan vars generate` procedure by pre-caching more selectors.
To achieve this, helper functions are added to several classes.
Also a debugging feature is added to the Flake class in order to track stack traces of cache misses
Make sure the user knowns that a git command is run.
From the issue #4588:
> It is confusing at times, when executing some CLI command, expecting change,
then checking git status but no changes are observed.
We now log:
- git add (debug)
- git commit (info)
The git commit information is formatted the following way:
```
Committed machines/backup-target to git
```
Alternatives:
Currently this shows to the user what happened.
But we might want to show the user what is being run.
We could print the information before invoking the `git commit` itself.
Informing the user of a potential password input window.
Closes#4588
