squash following commits:
- 32f5332b05a6064169e6cc07d9c4a60b6a3dc7c5
for configgitlab-pages/config
- f974a0197c74ca17343e5e3ff99a633347d8ad67
for config/gitlab-shell/config.yml
- 1104bacb29ed7f20bdf20015552299bd08ae7313
for config/gitlabhq/cable.yml
- 6ce37d8706cb289136385a7c498ad8c42faaab2c
for config/gitlabhq/resque.yml
- 7336e042728f63da2cc302b6fd6f975eb26566dc
for config/nginx/gitlab
- 1f39dcaabe7d3daa3b70ef0ae98ea8e30659e1e0
for config/nginx/gitlab-pages
- 76aaf571e992c6e5b970a437f8c46158d9867d65
for config/nginx/gitlab-ssl
- 549f717ec0810c8e11f30fb40f08997c0b84b5e3
for env-defaults but without KAS-related configs
(original: add WEBTOKEN secret, remove GITLAB_KAS_SECRET)
Authentication tokens are allowed to be part of URI and therefore they are printed
in the access log. This can be a security concern especially when system and
application logs are being send to an external logging system (syslog, wazuh,
splunk, etc.).
GitLab 8.4.0 requires a working database connection while executing the
`assets:precompile` raketask. As a result the execution of the rake task
is postponed to execute at runtime with the assets cached in the data
volume. This adds a noticable increase in the container startup time.
When relative_url is in used, the links to assets in the
`application.css` file to not have the relative_url prefix. To fix this
we proxy pass asset requests to the upstream gitlab unicorn.
Fixes#521
