equivalent of docker-compose run: start and attach to process (stdin\stdout) while running deps in background

[adrian-gierakowski]

Feature Request

I'd like to be able to run a selected process in forground, with stdin\stdout attached, so that I see it's logs and interact with it from command line. All of it's dependent processes should run in the background (no logs output shown in terminal).

This would be similar to docker-compose run $SERVICE_NAME

For example, given the following docker-compose.yaml:

services:
  main:
    image: busybox
    command:
      - sh
      - -c
      - |
        echo running main; while true; read -p "enter some text: " reply && echo $$reply; done
    depends_on:
      - deps

  deps:
    image: busybox
    command:
      - sh
      - -c
      - while true; do date > deps; sleep 1; done

when I run docker-compose run main, I see the following:

[+] Running 1/0
 ⠿ Container example-deps-1  Created                                                                                                                                          0.0s
[+] Running 1/1
 ⠿ Container example-deps-1  Started                                                                                                                                          0.2s
running main
enter some text: 

which then allows me to provide input at the prompt

the deps container keeps running in the background until the main process exits.

Use Case:

I'd like to be able to run tests as the main process and a bunch of deps (databases) as other processes in the background. The main process needs to wait for deps before it starts. I am only interested in seeing the test logs in the terminal, and I'd also like to provide input to the test process while it's running: for example, the jest test runner, when ran in --watch mode, can be controlled with various keyboard shortcuts which allow to rerun all tests, or only ones that failed.

Proposed Change:

Addition of:

• top level run command, taking 1 process name as argument: this would start all process defined in the config file, while attaching to the named process
• run sub-command to the process command, taking 1 process name as argument: this would start (and attach to) only given process. with all processes in it's dependency tree running in the background

a --no-deps flag could be nice to have

Who Benefits From The Change(s)?

People who'd like to use PC to interactively run some process, while also running other process on which the main one depends

Alternative Approaches

One could run deps in PC, while the main process outside of it, and use a wrapper script to start\stop PC as needed.

Also, a workaround I am currently using in CI, when running test process and it's deps via PC (with a config similar to this), is a following bash script:

process-compose >/dev/null 2>&1 &
pc_pid=$!

process-compose process logs tests -f &
test_logs_pid=$!

wait $pc_pid
kill $test_logs_pid

This way only output of tests process is shown in CI logs.
However this would not work if interaction with the tests process was required, like when running tests via jest --watch.

[adrian-gierakowski]

somehow related to #64

[adrian-gierakowski]

it would be great if anything that follows the service name would be passed to the main process as command line argument, so the usage would be

process-compose [PC_ARGS...] run SERVICE_NAME [SERVICE_ARGS...]

[adrian-gierakowski]

Any idea how much work this could be?

[F1bonacc1]

Hi @adrian-gierakowski,

I started to look at this issue before I had to deal with other things. Today there is no good way (at least a way I could find) to embed another process with stdin into the TUI 3rd party that I use.

Will it work for you if I provide this functionality without TUI?

BTW the --no-deps flag is already there.

In any case, I will try to contact the rivo/tview developer for assistance. I saw that many have tried to achieve something similar, but there are no documented cases of success...

[adrian-gierakowski]

Thanks for looking into this @F1bonacc1!

My use case is for running tests, either as one-shot execution in CI or interactively (in —watch mode) during local development. So TUI is not required.

I have actually implemented what I need yesterday while flying back from holidays, I’ll push the branch later tonight and share here so we can have a discussion about it.

[adrian-gierakowski]

opened a draft PR so we can discuss the implementation: #89

[thenonameguy]

Just to add to this discussion, I'm having to resort to this quite lengthy bash script, since there is no easy way to integrate the process-compose readiness into a linear bash script at the moment for CI test runs:
https://github.com/schemamap/schemamap/blob/main/devenv.nix#L77-L104

[F1bonacc1]

#89 Is merged in v0.75.1
Thank you @adrian-gierakowski !!!