[1337shadow]

Back in the days GitLab made it clear that it aspires to be a software company rather than an infrastructure company.

The reason I favor GitLab over GitHub is that I can install it on a dedicated server and have blazing fast performance, which helps development performance on an every day basis.

I've been maintaining a bunch of deployments of all sorts (k8s, docker-compose, baremetal) for the last years for several customers of all sorts of size, the upgrade process has always been pretty smooth, sometimes I ran in edgecases yes but always found a solution.

My deployments are always up and kicking, unless I'm messing with the configuration and doing some mistakes.

I highly recommend hosting your own GitLab instance, even on a single server.

[oefrha]

> have blazing fast performance

Sorry, but GitLab has never been blazing fast. The gitlab.com instance is notoriously slow — supposedly improved a lot over the past few years, but still feels pretty sluggish. My self-hosted instance isn’t much better.

In fact, a couple of open source maintainer friends looked into migrating to GitLab when GitHub was acquired by MS; they did not precisely because GitLab was too slow.

[1337shadow]

Let me clarify: git clone/fetch/push on gitlab.com or github.com is sluggish, but on my private instances it's blazing fast, because I get great and un-metered bandwidth from my dedicated servers which might not be the case for everybody / every country.

Another thing: CI starts the very second I push, and since I configure dedicated runners extremely well GitLab makes it easy keep every pipeline stage under 5 minutes, which is critical to me, as such I recon I have acquired countless tricks for that matter.

Also, the ChatOps integration (GitLab to Mattermost or Slack) seems instant for me.

Those factors matter for me because I'm an extremely fast iterator and often iterate on several repositories at the time.

The cherry on the top is that the mirroring between my gitlab instance and github is also blazing fast.

As for the web interface, well they all feel slow to me so I don't spend my time waiting for them so it's ruled out of the equation for me anyway, I'm just far more comfortable with command line anyway.

But, pushing to gitlab prints out the URL to create a pull request from that branch, or to view the existing one, also a time saver that's not available on github, not sure why though.

[chriscool]

> pushing to gitlab prints out the URL to create a pull request from that branch

You can use push options to automatically create a pull request and set it up when you push:

https://docs.gitlab.com/ee/user/project/push_options.html

[AdamJacobMuller]

Had no idea that existed, super cool, thanks!

[oefrha]

> pushing to gitlab prints out the URL to create a pull request from that branch, or to view the existing one, also a time saver that's not available on github

IIRC I’ve seen that recently with GitHub too. Not very useful to me though since I use magit for almost all git-related operations.

[FanaHOVA]

Yea GitHub has had this option for at least a couple months now.

[mcny]

You should look into git request-pull. I haven't gotten it to work but I'm probably doing it wrong. It should work.

https://git-scm.com/docs/git-request-pull

[frant-hartm]

From my experience a custom GitLab instance is much faster that GitHub.com. But it is apples and oranges and I suppose your friends weren't comparing the two.

[oefrha]

My custom GitLab instance is still slower than github.com. (Yes, I’m giving it enough memory.)

[lbotos]

If you are a customer you can file a support ticket and our Support Engineers can help troubleshoot. One of our mandates is "performance is a feature" and we want to better understand what's happening in the wild.

If not, and you are interested, we built a tool we use called "fast-stats": https://gitlab.com/gitlab-com/support/toolbox/fast-stats

it might be able to pinpoint what controllers are slow for your own curiosity.

[oefrha]

I'm a community user, and the sluggishness seems to be a common sentiment so I'm not sure profiling my instance will add anything valuable that's not already known.

(Sorry if my comments sounded entitled.)

[Aeolun]

It’s slower than github.com, but I wouldn’t call it slow.

What’s slow is out bitbucket datacenter edition.

[erikbye]

Not to mention consuming way too much memory. I prefer Gitea, or cgit if I need even less features.

[1337shadow]

Indeed, you can use drone-CI with Gitea that's also an option. But for now I find Gitlab-CI still slightly better: graphical representation of the pipeline, editable environment variables, review-stop jobs to clean up review deploys, automatic review-stop on MR merge ... Anyway, I run both because some people really want to keep their main repo activity on GitHub "for visibility" (for me that doesn't stand: I use gitlab->github mirroring feature as such my work is still published on github)

[stevekemp]

> the upgrade process has always been pretty smooth

By contrast I've managed a self-hosted install a while back, upgrades regularly broke as much as they fixed. For example the time when LDAP logins all failed, the gitlab-pages stopped working, and more.

That's on top of the constant UI churn with the side-menu, and similar changing from release to release with no rhyme or reason.

I wanted to like it, and did like the runner/CI support, though even that had as much pain as love. (Hard to script installation of agents, etc.)

[1337shadow]

For me they got the UX/UI pretty right since last release, I enjoy it both on mobile and desktop devices.

Anyway, for CI-runner setup, I have a one-liner that worked for me: bigsudo install lean_delivery.gitlab_runner @somehost gitlab_ci_token=yourcommand gitlab_host=yourlabs.io gitlab_runner_limit=4 gitlab_version=11.6

But also a docker run does the job... Well, there's still registration of runner that I did manually, but I just checked ansible documentation and it really looks like I got a fair chance to achieve that too, given all the new modules ansible got since 2.8 to deal with gitlab, including gitlab_runner and gitlab_runners modules: https://docs.ansible.com/ansible/latest/modules/gitlab_runne...

So yes, Gitlab strives to keep development and releases coming, that means sometimes foundations move, and that there's a learning curve too, I understand that some people may not like that, but as a dev myself I like it this way, and at the end of the day my team iterates great with GitLab-CI, we got automated review-deploys in less than 5 minutes with just docker-compose and that's really helpful to keep the master branch clean, this allows features to be merged only after they have received product team approval so that's a big win. With GitHub you can also do it with Drone-CI which you might like better because it's easier to setup even though it remains behind GitLab-CI in terms of features that matter to me.