Comment by maktouch | Hacker News Reader

Comment by maktouch | Hacker News Reader

Parent Full thread

We moved from Gitlab to Phab a year ago.

Context:

- One of the main repo is a monorepo in Git with over 40~ services

- We have a lot of smaller repos that are outdated or depreciated.

- We have an extensive pipeline that builds Docker images using Google Cloud Container Builder

Here's the pros:

- Speed. Gitlab is so slow; it's actually one of the main reasons why we moved out of it.

- Phabricator's Maniphest > Gitlab Issues by a long shot

- We prefer patch-based workflow. It makes Git history pretty.

- Code review is so much better in Phabricator, again, by a long shot. It's faster and the experience is a lot better.

- Herald (if-this-then-that for source code) is the bomb. We have a big list of rules, example: detecting `dangerouslySetInnerHTML` in our frontend service and adding blocking reviewers.

- Git management is pretty dope, setting it up so that it mirrors somewhere else is pretty easy. In our case, we just made it so that it mirrors to Google Cloud Repository (for GCCB to work)

- Cluster mode is included, which is useful because we're setting up a mirror Phab Repo in Russia for our team there - Meme editor makes things more fun (but its kinda shitty that it doesn't accept GIF =\) - The dashboard editor is very powerful and useful. - We had teams using SVN and teams using HG. Phab supports them all. That's pretty cool.

Here's the cons:

- Harbormaster, the CI, is the worst. It's seriously super complicated and not powerful at all.

- To replace Gitlab CI, we moved to Buildkite since there's an integration with Phab. Buildkite is a lot more powerful than Gitlab CI, and the syntax is similar.

- The concept of "staging" repo is super confusing.

- Setting up "merge" from the UI is very complicated and buggy

First time I hear about Buildkite. It looks pretty cool. Care to talk about it some more? Screenshots maybe?

I love buildkite and I wish they had better pricing model -- we would definitely love to pay for more.

Pros of buildkite:

- Very powerful. Plugin system is amazing and easy to extend. We wrote our own buildkite-docker executor, and I merged a lot of parts from it to the docker plugin upstream

- UI is a lot prettier and responsive than Gitlab's

- Dynamic pipelines !

- Hooks are extensive and powerful. Precheckout, Checkout, PostCheckout, precommand, command, postcommand. You got it all.

- The GraphQL API is amazing, and probably one of the best API I've used in my life.

- Pipelines are composable. You can make a yaml include another yaml. This was our biggest gripe with Gitlab since we use a monorepo and it got pretty big

- I know for a lot of people it doesn't mean a lot, but I like emojis in the output

- Agents are not stored like Gitlab. In Gitlab, once an agent connects, it gets stored in the database and never disappear until you delete it. It's problematic for our use case, because we use pre-emptibles node to save cost. It's 30% of the real price, and it dies every 24 hours. after 3 months, our Gitlab got super slow because it retained all the infos on all runners that existed. I had to make a script that deleted it from the database.

- Job retries!

- Docs are pretty dope

- Annotate is very cool (https://buildkite.com/docs/agent/v3/cli-annotate)

- Block step. Useful for confirming before deploy or something.

- Pretty cheap (unlimited builds, you pay per user). Honestly, I would love to pay them more.

Cons of buildkite:

- It's not free, so Gitlab is hard to beat on that.

- Gitlab works fine for 99% of the use case.

Take a look at their changelog, a bunch of screenshots and you'll see their development pace =)

https://buildkite.com/changelog

Have used Buildkite at a previous workplace. Really liked the UI. This is coming from someone who has used Jenkins, Travis, Codeship, and GitLab CI.

Their front-end is open source: https://github.com/buildkite/frontend

However, if you add your own CI runners, you'd have to clean them up periodically. This was the biggest issue for us, because even after cleaning them up from all docker images once a week, builds would get stuck.

Lox from Buildkite here. We have a docker-compose plugin that has a cleanup hook at the end of it for cleaning up docker containers and networks from your build. https://github.com/buildkite-plugins/docker-compose-buildkit...

We run buildkite-agents in its own kubernetes cluster, and the nodes are pre-emptible on Google Cloud so 30% of the price and it dies everyday, so it gets cleanup automatically

Can you expand on that? Do you mean if you're running your own Buildkite agents, there's a manual gc process devops should be aware of?

Love buildkite. It's insanely affordable too, and I like using it more than any other CI tool.

For speed alone, I wonder how Gitea would compare to Gitlab.

Gitea is written in Go. I used it for a small self hosted instance; it's fast for me, but I wonder if it scales well.

When I looked at Gogs, the code was really messy, had trivial SQL injection vulnerabilities in the past and the maintainer actively resisted efforts to implement basic features like OAuth2.

Is Gitea any better?

> the maintainer actively resisted

I hear that's exactly the reason why Gitea forked from Gogs.

In the past month, Gitea merged ~110 pull requests and got 70 new issues, and Gogs 7 and 18. Gitea also has 1500 (30%) more commits. All of this indicates to me that Gitea is further along than Gogs. Mainly based on that I went for Gitea and I like it so far, but I didn't install Gogs so I can't compare directly.

gitea user here, still I put gitea behind ssh as I am uncertain if gitea is robust enough to face the internet directly.

Gitlab is nowadays also almost entirely written in Go – every part that’s slightly slow has been rewritten in Go over the past years.

Still, that doesn’t help much. Gitea just does a lot less than Gitlab behind the scenes.

GitLab itself is almost exclusively Ruby. Go is used in several newer services (pages, ci, gitaly, more).

See https://gitlab.com/gitlab-org/gitlab-ce/graphs/master/charts for the core server.

Sure, but all the performance-critical stuff is in gitaly and the others.

And Phab is written in PHP, if some of the posters from previous HN discussions about PHP were to be believed there would be no point even looking at this software compared to one written in Ruby.

Comparing PHP to Ruby brings me back to 2012.

Since then php got faster, laravel copied many Rails concepts and improved in many areas. PHP is getting more popular while Ruby/rails is losing marketshare.

Those who still compare are living in the past.

I don’t normally upvote PHP projects, but when I do it’s usually Phabricator. It’s a high quality project regardless what language it’s in.

    We prefer patch-based workflow.
    It makes Git history pretty.

What is wrong with the feature branch approach? Before you merge a feature branch, you can squeeze all its commits into one. That leads to a pretty history too.

This is basically how you use Phabricator locally. Phabricator looks at patches to do code review, but the "arc land" CLI command takes your feature branch, squashes the commits, rebases onto master, and pushes that. So local development can use feature branches and the main repo has a normal git history. (Github added support for "squash and merge" maybe a year or so ago; same idea)

That's basically the same thing, just with less bells and whistles.

> Before you merge a feature branch, you can squeeze all its commits into one. That leads to a pretty history too.

With Github, you'll end up with a history like:

    Implement feature A
    Merge #1 Implement feature A
    Implement feature B
    Merge #2 Implement feature B
    ...

you basically end up with twice as many commits than you would otherwise. The other problem is that each commit ends up being rather big and the commit message is a combination of all the commits that were squashed, including ones that don't really contain any useful information (e.g., "Addressing comments").

A big commit is harder to revert (without encountering conflicts).

Use squash and merge instead. It's built right into GitHub, that way your history will look like:

    Implement feature A
    Implement feature B

In either case, you end up with commits that have large diffs and touch many parts of the code base. Most features require multiple commits to implement. As far as I know, Github does not provide a facility to squash into multiple commits.

I don't find it as pretty as Phabricator's

"Merge branch 'dev-hello' into 'master'"

Phabricator makes it so that the squashed commit summary is the summary of the diff (merge request)

GitHub has a similar workflow - you can use "squash and rebase" as merge strategy, which adds a reference to the PR to the subject and combines the text of all commits into one.

But like the parent said, it's not nearly as fancy.

Of note is that in this workflow, the commit message is not subject to the same review process as the code and (hopefully) documentation etc, since it's in effect written by the user merging rather than the user committing.

I have not noticed any performance issues on GitLab. Were you using their free plan by the time you switched?

Somewhere around 2016 and 2017, Gitlab made many performance improvement. May be OP was referencing slightly earlier? ( Or not )

Depending on who you are ask, Gitlab today is usable or Ok. I don't think anyone would call it fast. I wish they could write up where those bottlenecks are.

I suspect they are talking about the self-hosted version.

You need to throw quite a lot of hardware at it for acceptable performance.

Reply on news.ycombinator.com