updating gitlab (from a source installation)

daudo

daudo

In the company I'm working for, we've been using gitlab for quite some time, long before the gitlab package in the ports tree arrived.

Because updating it purely from it's sources can be quite difficult from time to time, we would now like to switch to the ports package.

The way gitlab works, it for example usually requires your to perform semi-automagic updates on your database for each released version. This is one of the reasons why you cannot simply upgrade eg. from 9.3 to 9.5, because your left out the upgrade steps from 9.4.

Now regarding the ports package I am wondering two things:

#1 is the ports package capable of "jumping" between more than one version?
#2 if not, what am I supposed to do if I miss to update to a new version?

regarding #2, I know that i can of course build older versions from the ports tree, but given gitlab's extensive dependency tree, this again doesn't sound like a very "easy" thing to do.

thanks in advance
 
I really fail to understand why anyone would want to use Gitlab over Git / Github together with some specific scripting, but alas. That's just me ;) Sorry, but the display of utter incompetence by Gitlab (setting up 6 backup schemes, not checking any of them and then actually losing data because of that) still somewhat bugs me.

Alas. Rhetorical question, just getting my bias out of the way. Best ignored ;)

So...

First of all keep well in mind that a port in FreeBSD is normally not that much different from the original project. The main applied differences would be a few patches in order to make it compliant with the way FreeBSD works. For example: 3rd party software from ports (and binary packages) always gets installed to /usr/local and not within the base system hierarchy. So if some software doesn't allow for this to be set through a ./configure parameter then it'll be patched.

But other than that there would be no significant differences. So if you cannot skip versions using the regular Gitlab software then it's safe to say that you also won't be able to do this using the ports version.

#2 is a question which you probably need to ask Gitlab or maybe the package maintainer. I'm assuming we're talking about www/gitlab right?

Code: 
peter@unicron:/usr/ports/www/gitlab# make maintainer
idefix@fechner.net
You could always try asking him.

But, as mentioned, this question is probably better presented to Gitlab. That's what you're (probably) paying them for and they should know their own software ;)

I'm not being sarcastic here mind you. Can well imagine that my small starting rant would give that impression, that's honestly not the case. But I could well imagine that the problem with skipping versions isn't limited to the port release alone.

However...

Are you sure you can't skip versions? While (briefly) studying the port I came across the update instructions and if I check 10.4 - 10.5 and compare that to 10.1 - 10.4 (note: doesn't this also skip some versions?) then I cannot help but notice that the instructions are pretty much the same.

Although they do mention MySQL commands those do not showcase any specific changes to the database itself. So solely based on that (not hands on experience mind you, I tend to steer clear from this) I can't help but conclude that those database changes aren't that extensive.

I would assume that you'll be perfectly safe when you upgrade to a minor release but that there might be consequences when you skip a major release. But considering the amount of major releases I think you'd have to be pretty negligent before you accidentally skip one of those.

Hope this can still be useful for you.
 
ShelLuser said:
I really fail to understand why anyone would want to use Gitlab over Git / Github together with some specific scripting, but alas. That's just me ;) Sorry, but the display of utter incompetence by Gitlab (setting up 6 backup schemes, not checking any of them and then actually losing data because of that) still somewhat bugs me.
Click to expand...
GitHub is proprietary code and self hosting is not possible even if you want to pay. There are situations in which even private GitHub repositories are not sufficient to meet either internal company requirements or cyber security imposed by government contracts. GitLab just like GO alternatives Gogs and Gitea uses Git as a backend of course. What we are talking here are web services with Git including bug tracking system, Wiki, continuous integration and much more. Personally I think for small to perhaps medium project Fossil is much better both as a distributed version control system and simple installation which provides web, bug tracking, Wiki and code review but for better or worse Git became industry standard.


daudo I am sorry I can't help you with your problem but I spend two long weeks few years ago evaluating GitLab as well as devel/gogs. I sympathize with your situation. GitLab was at the time of my evaluations slightly more mature and feature-rich product but I was stunned by the shear complexity of the installation (pretty much all Ruby modules, Ruby database as well as PostgreSQL). It is also very resources hungry. We went the way of devel/gogs before it was in ports and never regretted. Less than half a year ago I migrated our installations (plural form is not an error) on to the ports and now is even easier. The only thing with Gogs over the years was a bit of political wrangling in Gogs camp which produced "fork" www/gitea but I am super happy with the original product. I run it on the tiny atom based FreeBSD jail host. Gogs shares these machine with bunch of other developer tools like Jenkins for example. Use the power of ZFS snapshots and replications (backup) for redundancy, versioning, and backup. Once it is configured (less than 10 minutes in case of Gogs) you can forget about it.

I would suggest you try to migrate your installation to ports. That would at least make trouble shooting easier as right now you are on your own.
 
Last edited:
thanks for the replies and sorry I didn't get back earlier.

Regarding the question why we're using www/gitlab instead of github, that is indeed not possible due to legal constraints. Just like Oko mentioned, for the software we develop and maintain it is mandatory that it resides on premise on self hosted infrastructure. Additionally, gitlab has some really nice out of the box features that we would not want to miss, like it's really excellent and very easy to use continuous integration.

Due to the number of existing projects including associated issues, users, wiki pages ... migrating away to devel/gogs is no real option or maybe only the last resort. Though I have to say that gogs has indeed matured a lot.

The steps to upgrade gitlab involve invoking a couple of ruby scripts, that do the actual update. From the outside, those steps look the same for almost every version, but it is what they do internally that makes the difference (like patching the database). So if you leave out one version, just like with unpatched source code, you will run into troubles because the diff does not match your sources.

But thanks anyway, I think I'll bug the maintainer directly and see what happens
 
#1 is the ports package capable of "jumping" between more than one version?
daudo said:
Now regarding the ports package I am wondering two things:

#1 is the ports package capable of "jumping" between more than one version?
#2 if not, what am I supposed to do if I miss to update to a new version?
Click to expand...
As former maintainer i can answer your question number one with: yes, most times. There are some cases where it is just better to do not do this, because you will need much more manual work to figure out conflicts. But yes, its possible.
For number two: "missing" is not really possible, since GitLab has a monthly schedule and the port does a good job to keep with it up. If thinks really screw up, you can build packages your self or go back in time in /usr/ports/
 
You must log in or register to reply here.
Back
Top