[Feature Request] [ RFC ] Splitting docker compose from .env

[Gornoka]

Have you read the Important information text above

• [X] Yes i did

Describe the feature

I think it would make sense to split the docker-compose files from the main readme to reduce the chance of merge conflicts.

Taking this idea one step further would be to move the environment configuration to another file as well so that both compose files/sections in the main readme would not need to be updated simultaniously whenever one of them changes.

Additional information

• [X] Would you be willing to help implement this feature?

Final checks

• [X] I understand that this is a feature request function. I also unterstand that if i use this to report a bug report, that my issue might be un-answered closed.

[jammsen]

Hey @Gornoka I know what you are talking about, that repo had earlier docker-compose.yml and i even had plans to add an .env.example to it, but then i realized i had to always manage docker-compose defintions when we want to integrate "Standalone, Server+Rcon, Server+Rcon for Portainer" and so on. Now you dont have 1 file to manage. But now you have many files to manage and the possibility gets greater to miss something. Thats why i did choose to follow the "fat" readme way. Hope you understand what i mean.

But im open to feedback, what thoughst and alternatives are there to consider?

[masonen]

I would suggest the folowing

Everything that is in the env vars of the docker compose files currently goes to a .env.default (or similar)

in your docker compose files you load this env file via

version: '3.9'
services:
  palworld-dedicated-server:
    #build: .
    container_name: palworld-dedicated-server
    image: jammsen/palworld-dedicated-server:latest
    env_file:
      - path: ./.env.defaul
        required: true
      - path: ./.env.override
        required: false

Then ask the user copy the default env file and maybe also provide a script to update the env file in case env vars will get added in the future.

If the user wants to override any of the default variables they can add them to the override file.

Possible extenstions: provide a bash script that automatically updates the default env file and maybe a make command that first updates the env file and after that starts the service for full convienience and ensuring that the env file keeps up to date with the latest release.

This wil drastically reduce the need of solving merge conflicts. Furthermore it will shring down and ease the compose files.

[Gornoka]

The double env approach seems very interesting for this application.

[jammsen]

@Gornoka The double env approach seems very interesting for this application.

Well kinda yes and no. Yes for experienced users that use it anyway and no for new-users 🤣

@masonen I would suggest the folowing

Everything that is in the env vars of the docker compose files currently goes to a .env.default (or similar) ....

That would kinda dublicate stuff to manage on the VCS side and increase merge-conflicts and not reduce them. Now have the docker-compose.yml to add again and an .env.example and keep the readme explained, now its 3 files to take care of, instead of the readme only, like it is now. Or am i missing something?

[Gornoka]

The duplication of the env var sections in the yaml sections of the readme would be less, and the overwrite file would not need to be pre-populated.

It would also more easily allow you to upgrade to newer versions of the dockerfiles without loosing your overrides. ( since the second file would be gitignored).

Regarding merge conflicts it would be easier for the VCS as changes are made to the specific files they are meant for and not 1 huge file.

[jammsen]

The duplication of the env var sections in the yaml sections of the readme would be less, and the overwrite file would not need to be pre-populated.

It would also more easily allow you to upgrade to newer versions of the dockerfiles without loosing your overrides. ( since the second file would be gitignored).

Regarding merge conflicts it would be easier for the VCS as changes are made to the specific files they are meant for and not 1 huge file.

Can you come in Discord and have a call* please? Not getting the full context sorry.

[jammsen]

We added this feature a general restructuring, thanks for the feedback, your call and opinion on this.

Im closing this issue as resolved, feel free to try it out and reopen again if needed.

If you like this project, please consider giving this repo and the docker-hub-repo a Star.