Branching/conditional flows in cassette files

[MattieTK]

Is your feature request related to a problem? Please describe. For non-deterministic flows that you are trying to record with vhs (eg. commands and scripts that hit external services), working out what has happened behind the scenes is complicated. You may also want to have a single cassette file cover all cases (eg. deploying a script for the first time and updating a script which have different outputs)

Describe the solution you'd like A branching mechanism in cassette files with syntax something like

If Wait@10s /regex/
    Type "Pattern found within 10 seconds!"
    Enter
Else
    Type "Timeout - pattern not found!"
    Enter
Else ...
    etc
EndIf

This would enable you to have different forks in your cassette depending on various terminal outputs.

Describe alternatives you've considered You could have different cassette files for each case, but determining which cassette to run might still be better via an import than through trying to identify the current state and running the correct cassette. Doing that via its own cassette feels like a more appropriate solution.

[hesreallyhim]

@MattieTK could you clarify a little more what behavior you want? i'm writing a little "pre-processor" to make it easier to write vhs scripts quickly.

do you want something that could produce a different gif each time the tape is rendered (depending on external/runtime conditions)? do you want something that produces two gifs? i can easily add this in.

[MattieTK]

Hi @hesreallyhim - thanks for commenting.

My need for this stems from wanting to record terminal sessions where the output depends on data outside of your immediate control. At Cloudflare, for example, depending on how you choose to deploy a worker, what services you have set it up with, and details like whether it has been deployed before will all affect the terminal output if you were to try and run a recording.

During my use of vhs to create this flow (https://x.com/MattieTK/status/1982963805417079261) I went through numerous iterations because running the command results in server side configuration changes that affect future runs. In such a case I would like to be able to ideally:

1. help vhs recover by writing a little bit of excess logic that helps dodge common issues that might occur.
2. see what vhs is running into as the recording is processing so I can alter future runs to account for any prompt gates or error output whilst still keeping the recording intact.

At the moment if vhs encounters a problem with the recording it just times out which is not super helpful, and if I can't necessarily predict exactly what the output from the session is going to be, you end up running into this problem pretty frequently.

[hesreallyhim]

@MattieTK ironically I haven't had time to make a vhs for this yet, but this is this little pre-processor i built, and one thing it exposes is called "Probe":

https://github.com/hesreallyhim/pre-vhs/blob/229a88afcbd780db2a51d708399621584b9b54da/src/packs/probe.js#L3-L28

 * Example:
 *
 *   > Probe /ready/ $1
 *   curl -s http://localhost:8080/health
 *
 *   > IfProbeMatched $1
 *   service is ready
 *
 *   > IfProbeNotMatched $1
 *   service is NOT ready

If you'd like to give it a spin, i'd love to get some feedback from users. if it's too complicated, lmk i'm going to take another pass at the documentation when i get a chance. the core functionality should be pretty intuitive though, regardless, and is meant to be a timesaver. Cheers!

https://www.npmjs.com/package/pre-vhs