Hi,
thank you for this awesome permission plugin! Everything is perfect, I have one request however.

Would it be possible to separate the database configuration from the main config.yml? Mabye an extra option in the config.yml database-config: database.yml or something?

Why am I asking this?
I am managing all plugins of my server and their configs with git. All changes of the configs are tracked in git. At startup of the servers I replace alle database connection variables in the config with a freshly generated MySQL password for the docker db container. I do not want to checkin and upload the changes everytime I create a clone of the server. Therefor I added .gitignore files for all of my plugins and their database.yml configs.

I am also willing to create a PR and do the change myself, if you accept.

Thanks and regards,

Michael!

Why not keep the password the same? There’s absolutely no reason to constantly change it.

It is not about chaning them. I do not want to include sensitive passwords in the git repository.

That’s a fair point.

Though keep in mind that you’re suggesting a breaking change, that only really benefits you and anyone else that works that way. Which is maybe a handful of people.
It would require either a migration feature or decent amount of documentation (which 50% will not read anyways and come complain).

Now I can see two reasonable options.

If you are using Sponge, the config format is HOCON. Which allows imports of other files. So you can easily move it to a different file

Or alternatively you keep a custom fork of the plugin. Meaning you implement the changes yourself and then just merge the master branch into your repo when there’s an update.

I'm familiar with using Git to track configs, I do it too! :)

I don't really like the idea of splitting the config file up, however what you're trying to do is still easily possible.

I personally would add placeholders in the config.yml file on the Git repo, and then replace those placeholders when the repo is cloned and deployed.

e.g. in the repo:

  # Define the address and port for the database.
  # - The standard DB engine port is used by default
  #   (MySQL: 3306, PostgreSQL: 5432, MongoDB: 27017)
  # - Specify as "host:port" if differs
  address: localhost

  # The name of the database to store LuckPerms data in.
  # - This must be created already. Don't worry about this setting if you're using MongoDB.
  database: luckperms

  # Credentials for the database.
  username: {DB_USER}
  password: '{DB_PASS}'

And then somewhere in your deployment script, replace those variables.

Below is a bash script example, but you could use whatever...

# define the secret database credentials
USERNAME="secret_username"
PASSWORD="pa55w0rd"

# then replace the variables in the config
sed -i 's/{DB_USER}/'"${USERNAME}"'/g' ./plugins/LuckPerms/config.yml
sed -i 's/{DB_PASS}/'"${PASSWORD}"'/g' ./plugins/LuckPerms/config.yml

Thanks for the tip, however I am already using exaclty that :)

My issue is that after I run this script the file is marked as changed and needs to be commited for the repo to be clean. I have a workflow where I "develop" new features of the server on a testserver, or staging server. Once everything is ready all plugin configs, server configs (with plugin configs as submodules) will be commited and tagged. Then the production server will checkout the configs, pull the latest docker image with all plugin JAR files and restart to apply the changes.

I completly understand that this feature would target a relativly small group of people. I am also not suggesting a breaking change, but an additional option that can specify the config file or otherwise is null.

...
storage-method: mariadb
storage-config: null # default
# storage-config: database.yml
data: ... # irrelevant if storage-config is defined

My issue is that after I run this script the file is marked as changed and needs to be commited for the repo to be clean.

If this is a problem, then you can just use git reset to revert the changes made to the file, and commit everything else.

Sorry, but the complexity this adds to the code doesn't really justify the benefit it brings to the vast vast majority of the plugins users.