Feature Request: Run a "sanity-check" program

[IngwiePhoenix]

Hello!

This is a very great project! I have been looking for a much smaller but still capable process supervisor compared to PM2 and this looks like it is exactly what i need :)

I would like to request/suggest a feature: Allow the user to specify a "sanity check". For instance, imagine this shell script:

#!/bin/bash

check() {
  command -v $1 >/dev/null
  if [ $? != 0 ]; then
    echo "$1 was not found!"
    exit 1
  fi
}

check go
check node

If either of these fail, the script exits with exit code 1.

What I would like to do is to run this before any of the processes are invoked as a way to introduce a script that verifies the environment if everything is exactly where it should be. :)

Again thanks a lot for this project, been playing around with it today a lot and it's great!

Kind regards,
Ingwie

[F1bonacc1]

Hey @IngwiePhoenix,
Thank you for the positive feedback and for giving this project a try.
A few questions about the request:

1. Is the check defined per command [optional] or globally?
2. Is the check invoked by passing an additional argument to process-compose or all the time?
3. If sanity is defined per command, will there be scenarios in which they run, but don't fail (code 1) the entire (global) sanity check?
4. In case the sanity check passes globally, does the process-compose run all the commands, or should it run independently (exit 0)?

Maybe I will have more questions in the future :)

[IngwiePhoenix]

Good morning!

You are most welcome!

1. Globally. It should just make sure all things are where and how they should be.
2. No, it should run before all processes. If it returns true, assume that everything is fine and proceed to start the processes.
3. This could be considered - but I think it'd be better if a per-process check failed, it should only mean that this process can not be started and should only affect dependees.
4. Depends on if the user supplied arguments or not. Like if they only want to run one process out of many, I think the global check should still run. You could consider passing a PROCESS_COMPOSE_PROCS environment variable to tell the check if it should limit its checks or not.

Feel free to ask! I am not very good with Go, so there is not that much I can contribute. More of a C and Nodejs guy. ^^;

[F1bonacc1]

Good afternoon.

I think I have a clearer picture of what you want to achieve.
I think that even today this is almost possible if you define the first process to be this check and all other processes are dependent on it. Or at least the first process in the chain is dependent on it.

The only thing that is missing is the ability to exit on process failure.
What do you think about the following:

1. I will add support to configure an exit strategy if the process exit code != 0. This will be optional. If not configured the behavior will be as today.
2. If configured and exit code != 0 the process-compose will gracefully terminate all the other running processes (in case of the preflight check there shouldn't be any) and exit with the same exit code as the check process.
3. As today, you will be able to disable/enable the check process in configuration.
4. As a separate feature, I will add the support to run specific processes by providing a CLI argument to process compose. This way you will be able to run all the checks individually and validate their correctness before running all the other processes.
5. There is a downside to this approach - the check process(es) will be visible in the TUI, I am not sure if this can be a deal breaker for someone.

What do you think, @IngwiePhoenix?

You are contributing a lot by using the project and thinking about new use cases 😊

[IngwiePhoenix]

Hey!

I think that even today this is almost possible if you define the first process to be this check and all other processes are dependent on it

Good point, didn't think of that. So basically:

sanitycheck:
  command: ./scripts/run-checks.sh

other_proc:
  command: ...
  depends_on:
    sanitycheck:
      condition: process_completed_successfuly

Like so?

What do you think about the following:

I like 2 a lot. 5 is not a big problem really - at least I don't think so.

You are contributing a lot by using the project and thinking about new use cases 😊

Haha, thanks! Most welcome as well. :)

[F1bonacc1]

Hey @IngwiePhoenix
Yes, exactly! Your code snippet sums up the idea.
BTW, even today the processes won't run if all of them are process_completed_successfuly dependent on sanitycheck.
I will implement 1-4.

[thenonameguy]

Thanks for the great issue @IngwiePhoenix!

My 2 cents on this as user is that instead of trying to treat the symptoms of an incorrect environment in process-compose, the problem should be solved externally, by providing the correct environment reproducibly and proactively.
Great tools for this purpose are Docker/Nix/Guix plus a bajillion other tools I am sure.
This way process-compose does not have to get bloated with a feature-set that does not really solve the problem.

Example:

• what if the go binary is present on the PATH, but is actually not the proper version?
• What if node was compiled with an older libv8 than needed?
• What if the MacOS/Linux execution environment distinction is important for OS-specific feature reasons and require separate binaries?

Handling this with bespoke shell scripts gets tiring/error-prone really quick, and process-compose can only short-circuit a faulty start.

Even so a simple bash function can accomplish this today:

# put this into direnv/virtualenv/whatever
export PRJ_ROOT=$(pwd)
pcompose() { $PRJ_ROOT/bin/check.sh && process-compose "$@" }; }

$ pcompose completion --help
CHECK: All good!
Generate the autocompletion script for process-compose for the specified shell.
See each sub-command's help for details on how to use the generated script.

Leaving you with the option to easily opt-out of the check by just invoking process-compose directly.

[F1bonacc1]

Hi @thenonameguy,
I agree with your approach for a local, single developer environment. It is clear and keeps the process-compose lighter and its configuration simpler.
However, for the multi developers environment, you would want to share your compose.yaml file and expect it to function in a similar manner, even if they run it without the wrapper script.
This can be achieved by adding the relevant checks and dependencies to the processes execution chain and, if needed, termination of process-compose (new functionality).

Something similar to what I proposed to @IngwiePhoenix :

sanitycheck:
  command: "which go"
  availability:
    restart: "exit_on_failure" #new functionality

other_proc:
  command: ...
  depends_on:
    sanitycheck:
      condition: process_completed_successfuly

[IngwiePhoenix]

Hey @thenonameguy !

instead of trying to treat the symptoms of an incorrect environment in process-compose, the problem should be solved externally

Not wrong, I agree! It's an idea I had to bring down the external programms needed mainly. I go between platforms a lot; my laptop does not have WSL or Msys - only Docker. My Desktop has WSL with Nix and Docker and my server is a pure Debian box with only Docker, no Nix. So, for "between platform goers", it might be easier to have that feature, hence why I suggested it.

Hey @F1bonacc1 ! Just noticed you linked a PR and subsequent commits; I'll goa nd check out the new additions!

Sorry for my late response, got a little side-tracked IRL... :)

[F1bonacc1]

Hi @IngwiePhoenix,

I added the ability to exit if the process fails exit_on_failure. When this is configured, process-compose will exit with the same exit code as the failed process.

This functionality is part of v0.21.0 release.
Please let me know if it works as expected for you.