Bashtard v2.1.0
Its been about another year since I made a post about Bashtard, its 2.0.0 release. Today marks the 2.1.0 release, meaning I’ve gone almost a year without breaking backwards compatibility. To me, this is a very good sign.
The release today isn’t as big as the 2.0.0 release was, mostly because most of the functionality I want to have is already present. Some new features were added over the year, though. The most important one is variable references. This allows re-use of a variable’s value for another variable. Its quite simplistic in how it works, due to the nature of Bashtard being written in Bash and trying to keep things rather simple and lightweight. It does however get the job done for most use-cases I had for it.
Another feature that was added in this release is the zap
subcommand. It is a
convenience command more than anything, simply removing an existing registry
entry without going through playbook_del()
. The use case for this is mostly
for testing new playbooks. I found that while writing a playbook I’d often
remove the playbook entry from the registry to re-run the playbook_add()
function to see if it works exactly as desired, and I wanted this to be more
convenient. In theory this new zap
subcommand is also useful for dealing with
entries of broken or removed playbooks.
For a future release I’d like to add import
and export
subcommands, for
making it easier to handle external playbooks. The import
subcommand is
intended to take an URL and optionally a name to simply add an existing
repository as a submodule in the playbooks.d
directory.
The export
subcommand should take a name as it exists in the playbooks.d
directory and turn it into a git submodule, so it can be pushed to its own
repository. The intent is that you can just make a regular playbook for use
within Bashtard, and if you decide “hey, this could actually be useful for
others in its current state”, you can simply export it, and push it to a
repository for other people to pull from.
Additionally, I would like to remove the backup
subcommand from Bashtard, as I
feel it adds a level of bloat and scope-creep which simply should not be there.
While this would result in a 3.0.0 release of Bashtard, keeping it just for
backwards compatibility seems a little silly to me.
I’m on the fence for the ssh
subcommand, as it seems more closely aligned to
Bashtard being used to manage several systems, and ssh can be very useful to
check something across your entire network. Considering the recent SSHd
vulnerability, it was quite
easy to run a single command across all my machines and get an overview of which
machines were affected.
Let’s see what the rest of this year brings in Bashtard changes!