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

Automate asciinema screencasts #6197

Merged
merged 26 commits into from Jul 6, 2022

Conversation

hexagonrecursion
Copy link
Contributor

@hexagonrecursion hexagonrecursion commented Jan 29, 2022

Fix #2909

Manually generating asciinema screencasts is:

  1. Tedious
  2. Time consuming
  3. Inconsistent
  4. Error prone
  5. Has to be done from scratch every time you want to change something

This is my attempt to automate the process

TODO:

  • automate the advanced usage screencast
  • automate the installation screencast
  • dynamically echo the current borg version
  • add color (if you want it)
  • add a more convincing emulation of data-to-backup
  • fake a remote system via /etc/hosts
  • figure out how to fake a remote system. I think docker-compose might help me here
    This is needed to run the following command from the basic usage example:
    borg init --encryption=repokey borgdemo@remoteserver.example:./demo
    
    I have figured it out: map remoteserver.example to localhost in /etc/hosts

@hexagonrecursion
Copy link
Contributor Author

I have found a good way to implement this - isolate the example form the host by using a docker container. This way I get a disposable system I can freely butcher modify as needed to make the examples work.

@ThomasWaldmann
Copy link
Member

Hmm, I usually don't use docker. Just ssh to localhost to simulate a "remote" repo?

@hexagonrecursion
Copy link
Contributor Author

It's not just the remote example. I need some safe place to make a mess without messing up the machine of the developer doing the recording:

  1. The installation example needs to actually install borg somewhere
  2. A faithful recreation of the basic usage example depends on /media/backup/borgdemo existing
  3. The remote example needs to ssh somewhere. In general I can't count on ssh being installed or configured a certain way on the developer machine. Requiring the developer to configure it manually defeats much of the benefit of automation. Automatically installing packages and changing configuration is likely to lead to all sorts of trouble unless it is done in some kind of disposable sandbox.
  4. The installation example needs wget, gpg and sudo. The basic example requires diff. What if diff, wget, gpg or sudo are missing?
  5. The installation example sudo w/o a password. Even if sudo is installed and the current user can use it, there is a manual step of pre-entering the password before starting the recording

Using docker seemed like a neat way to make a mess and clean it up.

I usually don't use docker

What do you use instead?

@hexagonrecursion
Copy link
Contributor Author

I usually don't use docker

I have been in this boat too, but now I am quite comfortable with it and the power is worth the learning curve.

@ThomasWaldmann
Copy link
Member

I use VMs and vagrant (for borg mainly for automated platform testing).

@hexagonrecursion
Copy link
Contributor Author

I guess I'll have to learn vagrant then.

@hexagonrecursion
Copy link
Contributor Author

@ThomasWaldmann I have found some time to work on this. Reimplemented installation and basic usage via Vagrant. Take a look.

@ThomasWaldmann
Copy link
Member

Thanks! Will do, but likely after 1.2.0 release.

@hexagonrecursion
Copy link
Contributor Author

This should be ready now.

@hexagonrecursion hexagonrecursion marked this pull request as ready for review February 23, 2022 20:47
@ThomasWaldmann
Copy link
Member

Found / fixed some typos (squashed the fixes into the changeset where they were introduced).

@ThomasWaldmann
Copy link
Member

ThomasWaldmann commented Jul 6, 2022

Next thing I will try is to adapt this for borg2 (we definitely need new screencasts there as a lot of stuff changed).

If I succeed, shall I just push the stuff to your branch? Guess you'ld need to open a new PR then against the borg2 branch.

Update: hmm, no, I'll just update it to borg 1.2.1 and merge it into master. borg2 update can be done later.

@ThomasWaldmann ThomasWaldmann merged commit 2418795 into borgbackup:master Jul 6, 2022
@ThomasWaldmann
Copy link
Member

Thanks @hexagonrecursion!

ThomasWaldmann added a commit to ThomasWaldmann/borg that referenced this pull request Jul 6, 2022
@hexagonrecursion hexagonrecursion deleted the expect branch July 7, 2022 05:03
@rugk
Copy link
Contributor

rugk commented Jul 7, 2022

Great thing and great idea to automate that! BTW, are the (new) screencasts already live? As https://www.borgbackup.org/demo.html still shows the old ones…

@ThomasWaldmann
Copy link
Member

@rugk https://github.com/borgbackup/borgbackup.github.io/tree/source/_assets there is the old stuff still.

guess one could have a look first at old vs. new and then, if all is ok, update the files there. PRs welcome.

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

Successfully merging this pull request may close these issues.

asciinema screencasts
3 participants