- 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
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.
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.
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
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.
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.
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.
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.
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)
> 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).
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.
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.
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.
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