feature: Added generate-compose script.

[sundargs2000]

[sundargs2000]

Hey @timabbott. This was what I had in mind. This is very rudimentary and might need more logic and error handling. I ended up creating .config where you can set the mandatory settings and any other passwords if they want to (we can change it to command line arguments).

[flavio-prado]

Why not have just a .env.example file with all possible configurations and add in the docker-compose.yml the following line

env_file:
      - .env

Only thing that would be needed for the user is copy the example file and change for it's needs without any extra installation.

[sundargs2000]

Need to add tests, linter and a workflow.

[sundargs2000]

Why not have just a .env.example file with all possible configurations and add in the docker-compose.yml the following line

env_file:
      - .env

Only thing that would be needed for the user is copy the example file and change for it's needs without any extra installation.

This would still require users to run a script to generate the secrets, right? We can update the .env file in generate-secrets script, could be a cleaner way to do things but issue would be users seeing a ready docker-compose.yml, they might do docker-compose up and face issues with the server, whereas in the current way they won't have a docker-compose.yml initially until they run the generate-secrets. Thoughts @timabbott @flavio-prado?

[andersk]

We should use env_file. There’s no concern about a missing env_file causing random server issues; docker-compose up will appropriately refuse to start if an env_file is missing.

[sundargs2000]

Got it. We'll be generating a .env from .env.example.

[klardotsh]

Looks like this has been sitting for about a year and a half; unless @sundargs2000 or @timabbott want to pick this back up, I might propose closing it as stale at this point, or I can see about adopting it to take over the finish line. Either way, we should probably move to get it out of the open PRs list through some means :)