Hi There,
is there some way i can test my self hosted gitlab instance. I want to be able to verify when i updated the instance that everything works fine. I had an issue when doing a major upgrade from 12 to 13 where i couldn’t access repositories anymore because of the hashed storage migration.
Kind Regards
Henry
I usually used my own tests steps.
Just use Gitlab template from AWS Marketplace. This is the quickest way of doing this. AWS offers fully functional GitLab instance.
Judging by your experience, if you were having troubles managing your own server-side things, I’d go with version hosted by gitlab itself. Its hussle-free.
Whichever version, there are far better solutions out there which can do exactly the same + even more. And they are also free.
====
For example :: in GitLab, essentails like security dashboard ( where all the vulnerabilities of your project are being listed on the go) is not available for every tier: only the 2 most expensive tiers has access to it. Seriously @gitlab-team, so basic functionality available from 2 highest tier only?
Just for comparison: here there is function called Security Advisories available without even logging-in…
And many more Stupid decisions.
Another thing Ive just found (Im self-hosting gitlab on AWS) is that docs that comes with GitLab self-hosted is far outdated (I didnt use AWS Marketplace; I installed GitLab on standard Ubuntu instance (type t2.xlarge) from official gitlab repo; so its not that AWS has outdated version; @gitlab-team just ommited it; on purpose I suppose).
What they didnt ommit, though, is some shitty quick action (available both from Issues and MRs) like tableflip which inserts some stupid ascii-like emoji.
Instead of this tableflip (which there was near-zero demand for) they should have introduce ability to relate issue/s to MRs (there is high demand for this feature; it falls on dead ears…). You can relate issue to issue, but thats it. Of course its stripped out of any action that could possibly be taken ( these are available after logging-in), but still security insights are available for free
@DerAstronaut usually problems occur during the upgrades for one of a few reasons:
So, without knowing what you did during your upgrade, it could be that you missed an important version which required some migrations to occur, or, the upgrade process was continued when migrations were still running on the server - these can take a while, most are quick, but others could take hours.
I played it safe, as I wasn’t sure of the upgrade path from 12.9.3, I basically upgraded every single release from 12.9.3 to the latest upgrade. So all remaining 12.x.x release, all 13.0.x releases, all 13.1.x releases, and so on. As you can imaging it was time consuming doing around 50 or more package upgrades, and finished in two days, since I ran 25 per day. Depending on server specs, an upgrade process can take 5 - 10 mins for each package, not including if we have to wait for migrations to finish.
And usually once each upgrade has finished, I wait for gitlab to start itself up which can take a couple of minutes, and then visit my URL in the browser. If it loads, great all looking good. I check the repositories are still listing files, I use gitlab-ctl status to make sure all services are running, and then continue the upgrade process. You could always do git pull and push as well if you wish to verify this in addition to what I wrote above.
Generally, if you follow those steps, you shouldn’t have an issue with the upgrade process. Oh, and one more thing, just make sure the VPS also has enough ram to run gitlab as well. This could potentially also have negative effects on upgrades if something cannot finish running. Minimum requirements show 4GB, but I think 8GB is far better for a more stable system.