Description

When LOG_LEVEL is not explicitly set, DMS logs a warning early on:

WARN  start-mailserver.sh: Log level '' is invalid (falling back to default 'info')

That is redundant (should only log when it's assigned an invalid value), so let's configure the fallback earlier and only log this when it has actually been set with an unexpected value.

I've additionally collapsed the series of conditionals against LOG_LEVEL to use a regex instead, then inversed the logic so we don't need a redundant branch.

Reference:

If the assigned value to the LOG_LEVEL ENV is invalid:

• We log a warning to inform the user like shown above
• Then modify LOG_LEVEL to info as a valid fallback value:
  • Later assigned to the equivalent VARS key, which will store the variable into /etc/dms-settings (fixes the ENV when shelling into the container or when another service is started by supervisord like change detection or our setup CLI).
  • Updating the LOG_LEVEL variable for any other script that may check it during startup.

The default LOG_LEVEL is effectively already info when unset/invalid (this differs from the actual _log call that takes an arg to classify a log by level before checking LOG_LEVEL to filter):

Default/invalid LOG_LEVEL would match this:

Thus we only show error,warn,info logs:

For historical PR reference of this logic:

• fix: Better support container restarts #4323 (migrated)
• scripts: new log #2493 (introduced)

Type of change

• Improvement (non-breaking change that does improve existing functionality)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• New and existing unit tests pass locally with my changes
• I have added information about changes made in this PR to CHANGELOG.md

Minor internal change, seems unnecessary to document in the changelog.