Enable and disable processes via environment variables

[richardcooper]

Feature Request

Allow users to control which process are launched when running process-compose up using environment variables.

Use Case:

I have a project which has a single process-compose.yaml containing all the services used by the project. Different teams members will have a different set of "default" services they want to run 99% of the time. E.g.

• The frontend dev usually needs to run the website and backend
• A backend dev needs to run the API site and backend
• A documentation engineer only needs to run the doc site.

It would be good if users could easily configure their own personal set of enabled/disabled processes without needing to edit or override the process-compose.yaml. The project has a .env file which is not checked into source control, so that seems like a good place to put personalisation.

Proposed Change:

Add two environment variables. One for enabling processes and one for disabling processes. Both are a list of process names.

• PC_ENABLED_PROCESSES="process1,process2"
• PC_DISABLED_PROCESSES="process3"

These variables are checked when running process-compose up without any processes defined on the command line. The values from the environment variables override the value of disabled (and is_disabled) from the config file. Any processes not mentioned in an environment variable use the disabled value from the config file as they currently do.

Who Benefits From The Change(s)?

Teams where there are multiple users of the same service-config.yaml who each wants to run a different subset of the processes with a simple process-compose up

Alternative Approaches

Team members could:

• Always pass process names via the cli. E.g: process-compose up frontend
• Write their own git-ignored override.yaml files

[F1bonacc1]

Hey @richardcooper,

Thanks for the feedback.
That's not an uncommon scenario, and it makes a lot of sense.
And exactly for those reasons, I added the override.yaml files support.
You mentioned that, so you are familiar with them.

Is there a good reason not to version control a few different configurations?

1. backend
2. website
3. api site
4. doc site

All the frontend engineers: process-compose up -f backend.yaml -f website.yaml
All the backend engineers: process-compose up -f backend.yaml -f api.yaml
All the documentation engineers: process-compose up -f doc.yaml

It might look not very ergonomic, but they can always alias those in their local zsh or bash.

[richardcooper]

We have so many different services and configurations that version controlling the common configurations quickly grows out of hand in a combinatorial-explosion way. And even then it wouldn't cover all of the possibilities.

So the only workable option would be to have devs customises their own git-ignored override.yaml. That would work ok, but seems less ergonomic that the env-vars. It's the difference between asking my team to:

• Add PC_DISABLED_PROCESSES="process1,process2,..." to your .env file (which already exists)

and

• Create a new process-compose.override.yml file containing the following

  processes:
    process1:
      is_disabled: "true"
    process2:
      is_disabled: "true"
    ...
  

Both are fine but, to my eye at least, the first is cleaner and easier, especially as the number of processes get's bigger.

There are also some circumstances like CI where injecting env-vars is easer than writing a file.

I understand not wanting to have multiple ways to do the same thing, so if you think the benefits aren't worth the cost that's totally reasonable.

[F1bonacc1]

I added support for that, and it will be available as part of the next release.