...to report newly created entries, so that we can re-use these new
entries in the library-using code (for example for ID reporting).
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
With this patch, IDs can be fetched from the CLI via libimagrt. This
gives us the possibility to automatically handle "stdin provides IDs" in
libimagrt with less boilerplate in the binaries codebases.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This patch adds the id reporting feature to libimagrt::runtime::Runtime,
where processed ("touched") ids can be reported to the Runtime and then
get printed to stdout if stdout is a pipe.
Other output is automatically redirected to stderr if stdout is a pipe
now.
The function already returns `Result<_>`, the only thing that had to be
done was refactoring the code for actually returning an error in that
case.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
With this patch, the log level aggregation is abstracted away by using
zero sized types and a macro to implement the whole thing.
This does not alter functionality, but makes the code more readable.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
::stf::fs::create_dir_all() takes any ref to `Path`, which is what we
have here, so we can leave out the allocation of a new PathBuf object
here.
Also remove the match by a `if let Some(_)`, which increases the
readability a bit.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
With this change, the cache is tested before accessing the filesystem,
which probably increases the speed if the cache has the entry, because
we avoid the slow IO operation.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This fixes a really ugly bug where the in-memory backend for the store
did not remove the entry from the in-memory hashmap on "move", but
simply copied it from the old location to the new one.
That caused tests to fail after the fixes introduced for the
Store::get() function which checked the filesystem and the internal
cache whether an entry exists before the actual "get" operation, because
an old entry would still exist after a move (only in the testcases).
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Fixes: 09e8619cf5 ("libimagstore: Move from error-chain to failure")
This changes the implementation of Debug for the FileLockEntry to be
more explanatory of how the entry actually looks like. It does not only
print the path of the store anymore, but also the location of the Entry.
Printing header and content would be still too much, tho.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This way we can control where the input comes from and the output goes
to (like we want to with libimagrt).
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This actually caused an error.
When executing `imag ids --verbose trace` for example, the `imag` binary
got the default value (as in `--verbose info`) supplied from clap. So
far, so good. Problem is that the implementation then forwarded that
flag to `imag-ids`, which resulted in the `--verbose` flag to be passed
_two times_ to `imag-ids`.
Somehow this is really strange, but it does not really matter. First of
all: A default of "Info" is still too high IMO. Default should be
warnings and errors, but no information printed. We like silent tools,
don't we?
Second is that the commandline argument forwarding mechanism of `imag`
is broken and this was a fix which helped debugging of the brokenness,
so this is acutally a step forward in this regard as well.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This feature is required for the `imag` binary. It allows the binary to
use the imag internal logger for logging its own log output.
We need to be able to initialize the logger from an external module (in
all imag modules, the Runtime::new() implementation takes care of this,
but as we cannot use that in the `imag` binary itself, we allow this
method to be public behind a feature flag).
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
