- role="button" was removed at some point during refactoring which broke how the story was finding buttons
- button no longer has automatic loading state, instead it is now controlled.
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
- api functions exist under api.*
- they accept an abort signal and return a promise
- they can be swapped out at build time depending on the platform
(e.g.,window.method on desktop, fetch on mobile)
- TanStack Query functions should only be used in components, and
only when we need its features, favoring simpler api.* calls
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
on closing the logging file descriptor some parts of the program still
had the old reference. This will replace the old fd with stderr to fix
errors raised
