First: desktop is great. It’s better than anything else I’ve tried for runbooks, and it scratches an itch I’ve had for a while (which is why I’ve been trying other tools).
Second, a gripe: the experience of editing is not great for me. I have vim in my fingers, and am not keen to learn a new set of keystrokes and shortcuts.
Finally, a question / request: is there a plan to allow external editing of files?
I think you are doing fancy, crdt-backed documents – a neato feature, for sure. But I’d be happiest with my runbooks in git.
I see there’s an ‘import runbook’ feature, so this gives me hope!
We now support offline workspaces! These can be pointed to a git repo, and files can be edited with a text editor.
The format is still a bit verbose, but will eventually be optimised.
Love to hear this, thank you! What kind of thing are you using it for?
Very far off, to be totally honest with you. Our data model is rich enough that you’d be editing a JSON file, which would be a pretty terrible experience. There’s a future where we support <some custom format> that’s both human readable/writable, but it’s unlikely to be soon. We will probably get vim binding support sooner!
We will reasonably soon support import/export, of the following
Full rich data (json blob)
Lossy markdown (we cannot encode all the data we work with into standard markdown)
A combination of the above
What attracts you most to git? Versioning/backup/etc?
So far: runbooks to automate tedious, terminal-centered tasks:
collect configuration
run a series of long-running python scripts
call some APIs
copy files to a bucket
etc.
What attracts you most to git? Versioning/backup/etc?
I work a lot in the terminal, which is how I started using atuin (pre-desktop) in the first place. So naturally, I want to stay in the terminal to edit files, share them with colleagues, etc. Especially as runbooks evolve with the software, how great to version runbooks along with the software?
Anyway, @ellie, thanks for the response! I appreciate how active you are here and on discord, and I think what you’re building is very cool.
I’d like to keep and point to a “blessed“ version of a runbook while it keeps evolving.
Even during my early experiments with Atuin Desktop, I already find myself thinking “let’s make a copy so that my next experiment isn’t destroying what I already have“. In git, I use branches for experimentation and keep main stable.
Eventually, a branch is done and I want to make this the new blessed version. How do I merge two versions of the runbook? What if the blessed version has evolved since I split off my branch? Easy in git, but it’s unknown how this will work in Atuin Desktop.
When I want to point others to some versions of a runbook, tags are really helpful, because they are like symbolic links - I can name them as I want, I can have multiple of them, and they can move (point to a different version) if needed.
For instance, the runbooks I have are tagged with the environment (customer) they are applicable to. After the customer env was upgraded, the runbook tag moves to point to the runbook for the now deployed version of the code.
SHAs are useful, too, but not as important as the above.
I am not saying Atuin should change from CRDTs to Markdown and git, but I hope the operations mentioned above will be possible. Personally, I am way less interested in collaborative editing than branching, merging and tagging.
I also test my current (Markdown+git) runbooks in CI (do they parse with pandoc, spell-checking, dead links), and I’d love to do that for runbooks written in Atuin Desktop, too.
Firstly, happy to share that we now have “offline workspaces” that are essentially just a directory! Delayed reply because I wanted to make sure this was all out before getting back to you.
Runbooks are atrb files, essentially just YAML. Rich markdown is something we’d like to work towards. It’s editable externally, but probably more verbose than you’d like to work with all the time.
Exactly what I was hoping to hear! Lmk if there’s anything else we can do to make it easier.
Not sure if this is exactly what you mean, but we’re currently working on being able to run runbooks from a CLI too! So would be totally usable in github actions.
Otherwise copy/paste between them should work as expected, and you can copy-paste between the atrb files in an offline workspace as well
Ok awesome, all of that should be possible with the offline workspaces in a git repo now! We went for YAML so that reviewing diffs is a bit nicer than JSON, though in the future I really want it to be some kind of markdown++
Our end goal is to also support all of this with our CRDT stuff too, but obviously it’s not there just yet