Per GITLAB_SHELL_VERSION in the latest gitlab releases it should be 8.3.3

Per GITLAB_SHELL_VERSION in the latest gitlab releases it should be 8.3.3

Oops, seems I accidentally looked at the master branch. Should I change this PR to include only the patch? Or just let it sit here until the next release the 22.?

GitLab will break for existing users after upgrading and garbage collecting, since /var/gitlab/state/home/.ssh/authorized_keys is not regenerated. Is there a place to inform users of this, or should we fix it for them with ExecStarPre= in the unit? Not a big fan of the latter, because it's not clear how long such a thing should persist.

Please only include the patch, it's easy enough to bump gitlab shell when updating the rest

@krav GitLab was bumped to 11.4.4, but gitlab-shell should still be 8.3.3.

So as @globin said, please remove the bump to 8.4.1 for now.

@globin can you verify this works, and we probably can strip

        # The gitlab:shell:setup regenerates the authorized_keys file so that
        # the store path to the gitlab-shell in it gets updated
        ${pkgs.sudo}/bin/sudo -u ${cfg.user} -H force=yes ${gitlab-rake}/bin/gitlab-rake gitlab:shell:setup

from nixos/modules/services/misc/gitlab.nix too?

@krav Is there anything missing from here, after #50962 being merged? Can you rebase this on top of master?

@flokli Done. I don't think there's anything missing, this is a reasonably simple change.

I squashed together the two commits changing remove-hardcoded-locations.patch, so it's more understandable that there's only a chunk patching lib/gitlab_keys.rb added.

@krav I stripped the authorized_keys file regeneration on each gitlab startup, and added a note about that to the changelog. I'm thinking about simply not backporting 658c865 to 18.09, so for 19.03 everybody will most likely already have a authorized_keys file that's using /var/run/current-system/sw/bin/gitlab-shell command :-)

@flokli I have to admit I wasn't aware of the rake task. It's a recent addition to the module, it seems @WilliButz and I were solving the same problem. Not backporting 658c865 sounds sensible. I've looked through the relevant gitlab rake code, and it seems to fork() into gitlab-shell to regenerate the keys, so with this patch everyone should get /run/current-system/ on restart.

@infinisil good to merge?

Squashed together be77bbd and 62e5de4 into a3ec5dc for easier backporting into #51072