Skip to content

Environment variables in the app

Sid Sijbrandij requested to merge environment-variables-in-the-app into master

Fixes #3717 (closed) and #3519 (closed)

Why environment variables?

We need environmental variables, they are an expected way to configure apps https://medium.com/@kelseyhightower/12-fractured-apps-1080c73d481c#.ntrdiyu4c

This causes many tools and to tutorials to make it easy to set environmental variables and harder to supply a configuration file.

So even though we agree they are not ideal https://support.cloud.engineyard.com/hc/en-us/articles/205407508-Environment-Variables-and-Why-You-Shouldn-t-Use-Them the market has spoken.

Why for GitLab the application and not for the Omnibus packages?

Environmental variables are also needed by people that do not run our Omnibus packages, for example natively bundled apps (Debian apt-get) and idiomatic Docker packages (Mesos, Kubernetes, etc.).

Of course it should work great with Omnibus packages too so any advise is welcome in that regard.

There is an MR https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/575/diffs to be able to set any variable in gitlab.rb via environmental variables. I think both that and this MR should be merged to solve the configuration problem for both Omnibus and non-Omnibus installations. When both are merged the documentation should be crosslinked.

Why uppercase?

Need to be all cap according to Google Shell guideline: "Constants and Environment Variable Names => All caps, separated with underscores, declared at the top of the file." https://google.github.io/styleguide/shell.xml#Constants_and_Environment_Variable_Names

Or as explained on http://stackoverflow.com/a/673940/613240 Keeping to this convention, you can rest assured that you don't need to know every environment variable used by UNIX tools or shells in order to avoid overwriting them. If it's your variable, lowercase it. If you export it, uppercase it.

/cc @JobV @DouweM @marin @jacobvosmaer @ayufan @pravi

Merge request reports