Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch to automation of asciinema creation with autocast #8040

Open
rugk opened this issue Jan 10, 2024 · 4 comments
Open

Switch to automation of asciinema creation with autocast #8040

rugk opened this issue Jan 10, 2024 · 4 comments

Comments

@rugk
Copy link
Contributor

rugk commented Jan 10, 2024

Have you checked borgbackup docs, FAQ, and open GitHub issues?

Yes

Is this a BUG / ISSUE report or a QUESTION?

No

Suggestion

Instead of manually creating asciinemas, which can be cumbersome and time-consuming, especially if your CLI output changes, you can automate this!

I stumbled upon https://github.com/k9withabone/autocast and it looks awesome as it automates all that stuff away.
You just have to upload your project to asciinema and that's it.

Just someone would need to write the script (kind of a playbook hehe) for it.

Edit: Oh sorry just saw you automated that in #6197 already. Great, just this solution does not need a whole VM and such things and seems more lightweight. So maybe an idea for the future.

/cc @hexagonrecursion BTW as original contributor of that feature

@rugk rugk changed the title Automate asciinema creation Switch to declarative automation of asciinema creation Jan 11, 2024
@rugk rugk changed the title Switch to declarative automation of asciinema creation Switch to automation of asciinema creation with autocast Jan 11, 2024
@hexagonrecursion
Copy link
Contributor

I don't recall. Didn't I already automate those?

@RonnyPfannschmidt
Copy link
Contributor

you did, OP linked your mr

as far as I'm concerned autocast is not a good idea for the future as it simply would replace a working tcl script with a yaml mess while not solving the isolation (main reason for going vagrant)

@hexagonrecursion
Copy link
Contributor

this solution does not need a whole VM and such things and seems more lightweight

I remember now. I originally used Docker because it's more lightweight than a VM, but ThomasWaldmann asked me to port it to Vagrant because he is more familiar/comfortable with it.

At a quick glance autocast appears to be a tool with a similar purpose to TCL expect (which I used). Both allow automated control of software that requires a terminal emulator (TTY). Autocast appears to be more special-purpose. There is a chance a more special-purpose tool can be an improvement over a more general-purpose tool.

If, however, your main issue with the current implementation is the use of Vagrant, the solution would probably be to port the existing tcl scripts to run on both Docker and Vagrant (or, perhaps, porting the existing vagrant file to allow using the Docker provider). Either way we do want isolation and reproducibility - both appear entirely orthogonal to autocast

@rugk
Copy link
Contributor Author

rugk commented Apr 4, 2024

Ah, I see, I missed the requirement for isolation, which is kinda obvious for a backup solution, yeah… it was just an idea.

That said, making it Docker (or better say) container-compatible (one could e.g. use podman, then it does not even need root)… it's probably a new issue, though?

As I said:

just this solution does not need a whole VM and such things and seems more lightweight

So yeah, this was my concern. And IMHO autocast looked to simple, I did not try your solution here in practise though (yet again because I have no vagrant installed…)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants