almarklein
List of variables for Docker
Heya,
I looked at the docs, but couldn't see anything regarding this.
Is there a list of all the variables that we can use within a Docker deployment for the app?
I could only find:
TIMETAGGER_BIND
TIMETAGGER_DATADIR
TIMETAGGER_LOG_LEVEL
TIMETAGGER_CREDENTIALS
TIMETAGGER_PROXY_AUTH_ENABLED
TIMETAGGER_PROXY_AUTH_TRUSTED
TIMETAGGER_PROXY_AUTH_HEADER
Given the amount of additional settings that are available, especially with the latest release (thank you!), I'm wondering if there is an easier way to implement them via variables.
Thanks!
All server configuration options are listed here.
Settings such as the time format are user settings that can be set (by each user) using the UI (via the settings dialog). Technically they could also be set via the web api.
I think what you're hinting at may be the option to set default values for these user-settings via server config variables? This is not currently supported.
I think what you're hinting at may be the option to set default values for these user-settings via server config variables? This is not currently supported.
Aye, specifically this.
Is this something that'll be considered further down the roadmap at all?
Thanks again!
I think it could be. Could you explain a bit more about the use-case? Currently I don't see that much of a benefit over just using the settings dialog 😄
@almarklein @modem7 found proxy vars easily, apparently, I'm the noob who couldn't figure out how to use them properly.
TIMETAGGER_PROXY_AUTH_ENABLED TIMETAGGER_PROXY_AUTH_TRUSTED TIMETAGGER_PROXY_AUTH_HEADER
I think it could be. Could you explain a bit more about the use-case? Currently I don't see that much of a benefit over just using the settings dialog 😄
So sorry that this ticket was forgotten about!
So, from a docker deployment perspective, anything that can be set prior to deployment is beneficial, especially if sharing configs with others/troubleshooting etc.
Whilst not strictly necessary, it is useful, rather than making sure UI elements and options are filled in in each individual deployment when an env var would be a quality of life improvement for all users, especially if multiple deployments are wanted.
Right. Well, the defaults are currently hardcoded. Replacing them with a call to os.getenv() seems reasonable!