Tags: ruby, programming, devblog, kbsecret
The KBSecret 1.3.x tree has just been released, after five prereleases.
This post will quickly summarize some of the important changes between the 1.2.x and 1.3.x versions.
All of the commands included by a default KBSecret installation now run in just one process, providing a substantial performance boost.
The original flow for executing KBSecret commands looked (roughly) like this:
kbsecretcommand translates list to
As a result, every
kbsecret command invocation (pointlessly) required the Ruby runtime and all
dependencies to be loaded twice.
As of 1.3.x, the flow for executing
kbsecret list looks (roughly) like this:
run!on a new instance of it
This only requires Ruby and all of the KBSecret dependencies to be loaded once. In local testing, this speeds up most invocations by around 40%.
As part of this change, KBSecret no longer distinguishes between "built-in" (meaning baked
kbsecret script itself) and "internal" commands — all commands included with
KBSecret are now "internal."
kbsecret commands now supports the
for filtering output by command type:
$ kbsecret commands -i stash-file raw-edit sessions new todo pass conf cp env help dump-fields login commands types list generators generator version rm session $ kbsecret commands -e yad-login dmenu-pass recovery audit-pass todo-list snip discover-sessions
As before, running
kbsecret commands without any flags prints all commands, internal and external.
KBSecret now supports adding aliases for commands via the
commands.ini file. Aliases are declared
aliases key under each command's section, and are space-separated:
[list] aliases = l ls print-all-my-records
As a result, all of these invocations do the same thing:
$ kbsecret list $ kbsecret l $ kbsecret ls $ kbsecret print-all-my-records
commands.ini file can be opened in your
$EDITOR by running
kbsecret conf -c.
As of 1.3.1, KBSecret's library and CLI unit tests have been integrated:
make test now runs both
via the same
rake task, rather than splitting them across multiple tasks. This has allowed for
the integration of coverage results into the CLI tests (which are currently at 96% coverage!)
I wrote an entire separate blog post on integrating code coverage into KBSecret's CLI tests, which you can find here. You might find it interesting if you've struggled with coverage reports across multiple processes.
As always, check KBSecret's website for the latest documentation (and references to the API docs).
Thanks for reading!