Hi.

 

So after managing to get my 14.8.x updated to 14.10.4

(thanks to the pointers in https://www.turnkeylinux.org/forum/support/wed-20220406-1031/gitlab-comm...)

I'm stuck updating to 15.0.x with a deprecation error "gitlab_rails['lfs_object_store_xxx_upload']" with xxx being direct and background.

 

Yeah, so I went to /etc/gitlab/gitlab.rb and commented both lines, but to no avail. So I'm hoping for more pointers here.

 

JFYI: That's still on a Debian stretch based TKL which I also would like to update/upgrade to something newer once that GL upgrade succeeds.

Forum: 
Tags: 

For reference, here is the full sauce:


Preparing to unpack .../gitlab-ce_15.0.2-ce.0_amd64.deb ...
* gitlab_rails['lfs_object_store_direct_upload'] has been deprecated since 14.9 and was removed in 15.0. Starting with GitLab 15.0, only direct uploads will be permitted deprecating this configuration key.
* gitlab_rails['lfs_object_store_background_upload'] has been deprecated since 14.9 and was removed in 15.0. Starting with GitLab 15.0, only direct uploads will be permitted deprecating this configuration key.
Deprecations found. Please correct them and try again.
dpkg: error processing archive /var/cache/apt/archives/gitlab-ce_15.0.2-ce.0_amd64.deb (--unpack):
subprocess new pre-installation script returned error exit status 1

Uh... Editing /etc/gitlab/gitlab.rb is a good 1st step, but it's not sufficient.

 

So yes, you edit that file and then you run

gitlab-ctl reconfigure

 

and THEN the upgrade works. I wonder why that reconfigure step cannot run automatically if it sees that the gitlab.rb file has been changed/touched.

 

Jeremy Davis's picture

Running 'reconfigure' is required to re-read config. That is relatively common with Linux services (most only read their config file at start time). It would be possible to monitor the /etc/gitlab/gitlab.rb file and auto reconfigure GitLab on changes, although I'm not sure that it would be optimal in all situations.

Regardless, I'm glad to hear you worked it out and thanks for posting back. I'm sure it'll save someone else some mucking around.

Hey Jeremy.

 

I didn't imply the gitlab reconfiguration should happen automatically at any occasion, I specifically meant the part when dpkg runs when updating, as this is the point of failure. So in my opinion there the script should check if the etc file has changed (usually that's exactly what happens anyway in many apps) and if yes, then run the reconfigure.

I agree that in other situations "trying to be that smart" might not be optimal, so I suggest to do it only in this situation. :-)

 

Jeremy Davis's picture

Sorry I misunderstood the context that you were meaning. With your added context, yes, I agree. The package should have a post-install script which runs the reconfigure command. IMO it's probably worth just running it anytime an update is done.

Add new comment