Hydra fails to build the assets on i686 - it runs out of memory. If we
limit the max consumption to 2048MB the assets still build, and will
hopefully also build on hydra.
For some reason hydra seems to have issues downloading the
gitlab-workhorse source on macOS. Since we don't build the rails app
for macOS, the other components seem a bit useless there, so we
limit them to linux for now.
- gitlab-shell no longer requires ruby for anything else than the
install script, so the bundlerEnv stuff could be dropped
- gitlab-shell and gitlab-workhorse now report their versions
correctly
On start, unicorn, sidekiq and other parts running ruby code emits
quite a few warnings similar to
/var/gitlab/state/config/application.rb:202: warning: already initialized constant Gitlab::Application::LOOSE_EE_APP_ASSETS
/nix/store/ysb0lgbzxp7a9y4yl8d4f9wrrzy9kafc-gitlab-ee-12.3.5/share/gitlab/config/application.rb:202: warning: previous definition of LOOSE_EE_APP_ASSETS was here
/var/gitlab/state/lib/gitlab.rb:38: warning: already initialized constant Gitlab::COM_URL
/nix/store/ysb0lgbzxp7a9y4yl8d4f9wrrzy9kafc-gitlab-ee-12.3.5/share/gitlab/lib/gitlab.rb:38: warning: previous definition of COM_URL was here
This seems to be caused by the same ruby files being evaluated
multiple times due to the paths being different - sometimes they're
loaded using the direct path and sometimes through a symlink, due to
our split between config and package data. To fix this, we make sure
that the offending files in the state directory always reference the
store path, regardless of that being the real file or a symlink.
The 2017.3 version of p4v is linked against `libssl.so.1.0.0`. Since
the default openssl in NixOS 2019.09 has been changed to openssl 1.1,
the p4v package must now import the openssl_1_0_2 derivation.
