While I'm a big fan of their team and culture approach, we yet to see better/respected GitLab.com SLA guarantees — it still feels like they're doing too much "testing on production".
While I'm a big fan of their team and culture approach, we yet to see better/respected GitLab.com SLA guarantees — it still feels like they're doing too much "testing on production".
Though I generally do like GitLab and favor Github alternatives over Github as I see it as a single point of failure for the FOSS community at this point.
> "testing in production" indeed. One of my repos has been stuck in limbo for over 2 months now
> after I attempted to migrate it to a group namespace from my own profile.
Have you created an issue for this on https://gitlab.com/gitlab-com/support-forum/issues?I'm not OP but I've got myself into basically the same problem; https://gitlab.com/gitlab-com/support-forum/issues/2291
I tried some various solutions via CURL to get the repository unstuck (basically rewriting the URL the request is sent to since the project settings page was pointing at the wrong repo) and it basically reports an empty repo on the target (which doesn't show up for me on my profile) and a 404 on the original (which does show up on my profile)
Agreed. However, if you need more reliability than gitlab.com it's not difficult to host GitLab yourself in a VM or on bare metal.
Many companies already have their own physical servers in a DC (either colocated or leasing). Hopefully the people managing these servers know what they're doing and can give the developers a good SLA. Although some additional work on file/DB syncing would be necessary to have a hot spare.
I like that Gitlab exists but I am willing to pay a lot of money to not have to manage yet another server
Certainly while github is occasionally down or misbehaving, there's no way any enterprise I've worked at could self-host with as much reliability as github.
We have a plan to address this and are kicking off our move to GCP shortly. Our top-level engineering department goal is to make gitlab.com ready for mission critical workloads and are targeting industry standard SLA's (e.g. three 9's). You can see our proposed architecture here if you're curious: https://about.gitlab.com/handbook/infrastructure/production-...