-
Notifications
You must be signed in to change notification settings - Fork 575
Conversation
Hello @paddatrapper, Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here. |
This PR has been automatically labelled "stale" because it hasn't had recent activity. |
Any update here? |
@paddatrapper Sorry for missing your contribution until now, appreciate your thoughtfulness here. We are in fact making some changes to the Mattermost Docker repository, and moving to a new project available at https://github.com/mattermost/docker. You can find additional context behind this move here: #548 With that said, would you be open to contributing your changes to the new repository at mattermost/docker instead, and we can have your changes reviewed? Sorry for additional work for you. Alternatively we can also open an issue in mattermost/docker to have your changes here migrated to the new repository. |
There is no entrypoint or docker image builds in https://github.com/mattermost/docker... So this patch will not fit there. It isn't clear where those images are built from. According to Docker Hub, it is here, but that has none of the config creation logic, so it appears that the new images do not create any config? |
@paddatrapper the Mattermost binary itself creates a configuration or reads in an existing one. In fact the https://github.com/mattermost/docker setup supports configuration in database. Just export |
@mrckndt so the new images do not require this patch? |
No, and this wasn't needed here too. It should have work by exporting |
From experience, it did not work here. That attempted to create the config file the datasource as the filepath, inevitably failing |
Summary
Adds a flag to support in-database configuration through the
CONFIG_USE_DB
environment variable. If this istrue
, the configuration file will not be created if it does not exist. It supports using the customMM_SQLSETTINGS_DATASOURCE
if that exists.On new deployments with
CONFIG_USE_DB
enabled, none of the defaults written into the configuration file are created. Further, it assumes existing installations migrate their configuration over before enablingCONFIG_USE_DB
as described in the documentation