This commit implements the following additional test cases for gitlab:
- Creating regular users
- git clone over http and ssh
- git push over ssh
- Forking projects
- Creating and merging Merge Requests
- Opening and closing issues.
Massively reduce the time it takes running the test by building a
proper root disk image and increasing the virtualized core count to
4. This should make it much easier for the tests to pass even on
weaker systems.
With my laptop (AMD Ryzen 7 PRO 2700U) as the reference system, I see
the following test run times:
- No change:
Times out after 28 mins
- Building a root image:
7 mins, 48 secs
- Building a root image and bumping the core count:
7 mins, 17 secs
The times include the time it takes to build the image
(~1 min, 20 secs).
This reverts commit d6e0d38b84.
We need shorter secrets to continue working, since the earlier
recommendation was too short and there's no way to rotate the them.
Test the automatic backup and restore functionality by backing up the
instance after running the initial tests, stopping GitLab and removing
all state, running the restore rake task, then running the tests
again, but without pushing data.
Add support for storing secrets in files outside the nix store, since
files in the nix store are world-readable and secrets therefore can't
be stored safely there.
The old string options are kept, since they can potentially be handy
for testing purposes, but their descriptions now state that they
shouldn't be used in production. The manual section is updated to use
the file options rather than the string options and the tests now test
both.
GitLab 11.5.1 dropped the dependency to posix_spawn, which is broken on
32bit. (See https://gitlab.com/gitlab-org/gitlab-ce/issues/53525)
The only part missing is decreasing virtualisation.memorySize to
something that a 32 bit qemu still executes.
The maximum seems to be 2047, and tests passed with that value for me.
The nixos test is a bit misleading, as the given nginx configuration
would always cause gitlab to redirect to localhost, which is clearly not
what you want in a production setup.
Instead we now enable services.nginx.recommendedProxySettings,
curl against http://gitlab, and assure we get redirected to that same
hostname, too.
