Add lifecycle script support via --script on env:up

[Luc45]

This PR adds the ability to run scripts during environment lifecycle:

qit env:up --script ./setup.sh

PS: I'm exposing this just on env:up and not on run:e2e as we already have the Orchestration Process in Custom Tests, and I don't want developers mistakenly using scripts instead of shared/isolated setup/teardown, which could easily break the purpose of the orchestration purpose to manage state in a compatibility test with multiple extensions.

The simplest usage is as above, but you can also run a command directly:

qit env:up --script 'ls -la'

Config File Example

You can also define scripts in a qit.yml|json:

scripts:
  env_started: './setup.sh'
  env_stopped: './teardown.sh'

Testing Instructions

1. Local script usage

   • Create a shell script, e.g., setup.sh:

     #!/bin/bash
     echo "Hello from setup.sh" > /tmp/test_script.txt

   • qit env:up --script ./setup.sh
   • qit env:exec cat /tmp/test_script.txt]
   • You should see "Hello from setup.sh"

2. Direct inline command

   • Same as above, but inline: qit env:up --script 'echo "Inline script ran" > /tmp/inline_script.log'

3. Config-based scripts

   • Create a minimal qit.yml (as shown above).
   • Run:

     qit env:up

   • Confirm that your scripts (setup.sh, teardown.sh) execute on startup or shutdown.

4. Teardown (Optional)

   • If you use a teardown script (env_stopped), add --script env_stopped=./teardown.sh or define it in qit.yml.
   • Run qit env:down -v and check logs/output to confirm the teardown script runs.

[zhongruige]

This is an awesome addition @Luc45! Quick question--do you think there's any scripts we should try and prevent them running? Granted these are isolated ephemeral environments but not sure if there's anything to be careful of.

[Luc45]

do you think there's any scripts we should try and prevent them running?

I don't think so. Everything is dockerized, and any local directory mounted outside the disposable directory is read-only on the host.

[singerb]

I'm exposing this just on env:up and not on run:e2e as we already have the Orchestration Process in Custom Tests, and I don't want developers mistakenly using scripts instead of shared/isolated setup/teardown

Cool change; given this comment though, I'm just curious about the motivation for adding this?

[Luc45]

I'm exposing this just on env:up and not on run:e2e as we already have the Orchestration Process in Custom Tests, and I don't want developers mistakenly using scripts instead of shared/isolated setup/teardown

Cool change; given this comment though, I'm just curious about the motivation for adding this?

It's like orchestration but for env:up.

[singerb]

I'm exposing this just on env:up and not on run:e2e as we already have the Orchestration Process in Custom Tests, and I don't want developers mistakenly using scripts instead of shared/isolated setup/teardown

Cool change; given this comment though, I'm just curious about the motivation for adding this?

It's like orchestration but for env:up.

Right, but as you say: custom tests already use orchestration and not this. Did we need this for something, or did vendors request it? That's what I'm curious about.

[zhongruige]

This is looking good to me so far, I did see @singerb left a question on this one to provide some context around the changes which would be good to have, but otherwise happy to add in my approval.