@afrepues Could you do me a favor and fix the gitlab test, then we should be able to merge this rather quickly. It is broken right now.

The gitlab test isn't easily fixable due to too much I/O for kvm to handle, I'd be happy if someone manages, but don't expect this to be easy

Maybe we should get rid of it instead then?

It generally probably would work if it didn't timeout so I'm reluctant of removing it..

@NeQuissimus how do I test it?

@afrepues

λ nix-build ./nixos/tests/gitlab.nix
error: The option `services.gitlab.secrets.secret' is used but not defined.
(use ‘--show-trace’ to show detailed location information)

@globin It does not run at all for me, it is missing config.

Ah I had fixed that locally but not pushed it since it timed out always..

I also have a local branch of the test (which also includes an nginx proxy in front of http://unix:/run/gitlab/gitlab-workhorse.socket which is necessary with the current module) but it times out even after 20 minutes in preStart) so I don't think it's very critical to fix it here. I can PR what I have soon, if we want a timing-out-test rather than a broken one.

I'm currently refactoring secret handling to allow a safe, filed-based solution,

You also need to update Gemfile and Gemfile.lock and rerun bundix, also probably needs to update gitlab-shell, gitlab-workhorse and gitaly to the versions in the XXX_VERSION files in the sources.

#31317 tries to improve the test situation slightly. As explained in this thread, it still dies due to timeouts.

@NeQuissimus Just reading through this... the test failure seems unrelated to this change.

@globin I will take a look at the changes in Gemfile*, and the versioning of the related programs.

@afrepues Just to clarify: Yes, the test failure is entirely unrelated to this change. :)

@srhb thanks!

@NeQuissimus @globin I have pushed a new set of commits that include the updates to the Gemfile* and the result of running bundix, updated versions of the related packages, and rebased to the master branch.

LGTM, it's too bad the test times out. I am going to assume you have tried actually running Gitlab?! :D

@NeQuissimus I am running Gitlab, though at 10.0.4 ATM.

@NeQuissimus Why did you merge this PR even though @afrepues admitted he didn't test it? Why didn't you at least test it before merging? Please wait for someone else to test it.

hmmm? as per discussion, the test times out. "the test failure is entirely unrelated to this change"

I reviewed the PR with nox (hence building it), I ran the test until it times out.
I was not too worried about this causing issues...

@fpletz @NeQuissimus for what it's worth, the changes weren't made by just downloading the archives and pasting the hashes, I actually read the released notes and besides the updates to the newer versions, no changes were needed to the Gitlab service.

Please do not do this again in the future without actually testing a fresh install and an upgrade of an existing instance. On my many gitlab bumps in the past, I've experienced a fair share of problems.

Gitlab frequently breaks compatibility for instance in regard to system configuration. They can fix this themselves with their omnibus packaging and the docker images but won't mention every change in the release notes. You should also read the upgrade notes but they aren't complete either. 😿

But of course: Thanks for the bump, very much appreciated. 👍