- 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.
GitLab recently restructured their repos; whereas previously they had
one gitlab-ce and one gitlab-ee repo, they're now one and the
same. All proprietary components are put into the ee subdirectory -
removing it gives us the foss / community version of GitLab. For more
info, see
https://about.gitlab.com/2019/02/21/merging-ce-and-ee-codebases/
This gives us the opportunity to simplify things quite a bit, since we
don't have to keep track of two separate versions of either the base
data or rubyEnv.
Instead of extracting prebuilt assets from the debian build, build
them from the source. This should give faster package updates and
reduces the amount of data needed to be downloaded by more than 500MB.
Split the remove-hardcoded-locations patch into two separate patches,
one for the ruby package and one for the go package. This is clearer
and results in fewer rebuilds.
- Update GitLab to 12.3.4
- Update update.py to cope with the new upstream repository structure
- Refactor gitlab-shell to use buildGoPackage and bundlerEnv for
dependencies
- Refactor gitlab-workhorse to use buildGoPackage for dependencies
- Make update.py able to update gitlab-shell and gitlab-workhorse
dependencies
- Various fixes necessary for update to work
There ver very many conflicts, basically all due to
name -> pname+version. Fortunately, almost everything was auto-resolved
by kdiff3, and for now I just fixed up a couple evaluation problems,
as verified by the tarball job. There might be some fallback to these
conflicts, but I believe it should be minimal.
Hydra nixpkgs: ?compare=1538299
This is a major version bump but things were generally straightforward
save two wrinkles:
* it is necessary to ignore collisions in the gitlab bundler
environment as both `omniauth_oauth2_generic` and
`apollo_upload_server` provide a `console` executable.
* grpc had to be patched since its build system expects the `AR`
environment variable to contain not just the path to `ar` but
also the `rpc` flags (see the discussion in nixpkgs #63056).
SSRF in Kubernetes integration
The GitLab Kubernetes integration was vulnerable to a SSRF issue which could allow an attacker to make requests to access any internal URLs. The issue is now mitigated in the latest release and is assigned CVE-2018-18843.
unix-tools.nix has a collection of tools that are commonly installed
by default in Unix derivatives. This is intended to provide
compatibility between macOS and Linux users. Three Linux-only
derivations are provided for compatbility:
- procps
- utillinux
- nettools
More tools are also provided.
Also: treewide: use unixtools
Non-comprehensive replace of Linux-only procps and util-linux with
'unixtools'.
Updates gitlab to the current stable version and fixes a lot of features that
were broken, at least with the current version and our configuration.
Quite a lot of sweat and tears has gone into testing nearly all features and
reading/patching the Gitlab source as we're about to deploy gitlab for our
whole company.
Things to note:
* The gitlab config is now written as a nix attribute set and will be
converted to JSON. Gitlab uses YAML but JSON is a subset of YAML.
The `extraConfig` opition is also an attribute set that will be merged
with the default config. This way *all* Gitlab options are supported.
* Some paths like uploads and configs are hardcoded in rails (at least
after my study of the Gitlab source). This is why they are linked from
the Gitlab root to /run/gitlab and then linked to the configurable
`statePath`.
* Backup & restore should work out of the box from another Gitlab instance.
* gitlab-git-http-server has been replaced by gitlab-workhorse upstream.
Push & pull over HTTPS works perfectly. Communication to gitlab is done
over unix sockets. An HTTP server is required to proxy requests to
gitlab-workhorse over another unix socket at
`/run/gitlab/gitlab-workhorse.socket`.
* The user & group running gitlab are now configurable. These can even be
changed for live instances.
* The initial email address & password of the root user can be configured.
Fixes#8598.
It turns out that installing therubytracer, with dependency on old v8, even
when using source libv8 version is problematic.
(see
http://stackoverflow.com/questions/21666379/problems-installing-gitlab-on-odroid-v8-lib-not-available).
But wait, rails does not even need therubytracer, just any kind of javascript
server side execution framework like nodejs. Well just use that, as also
suggested from different internet sources (look link above), it works just
fine.
