Phabricator on the other can supports `git`, but that's just one of the supported storage systems for phabricator. As a user you are using `arc`, phabricators command line tool.
I've seen many people having issues with using `arc`, having used, say github, prior to that. This got better recently when the `arc land` workflow was improved.
Phabricator is much more flexible and that comes with a small cost in complexity, but the result is a system which provides a superior workflow, especially in enterprise environments:
When I see Phabricator I just don't see anything. I just see a blob of text dumped to the screen. Maybe it's because I'm so use to Github.
It's the little things that GitHub does, that I've found makes the difference. Take GitLab's branches page here:
By limiting the number of branches shown and by creating strong visual breaks/barriers, they make it way easier for the user to focus. Seeing a wall of branches is okay ... when that's what you want, but as a default, by organizing it the way that GitHub does, they make their branches page significantly easier to consume.
I also find the buttons too be a little too big in GitLab and they don't have enough definition to them, to help you focus on them. Creating merge requests and comparing branches is the focal point of the branches page, and they should make it easier for your eyes to lock onto them.
Like I said, it's the little things that I can't explain that I've come to respect and I don't think it's just because we are familar with GitHub.
I really like what GitLab is doing, but I also really like a powerful web-based repository browser (search tool included). Hopefully they just went a bit wild with the UI and they'll rein it in. (I also checked Preferences and they have a switch for fixed vs. fluid layout, so maybe they've been responsive to UI-change revolt in the past?)
The switch was surprisingly controversial, as the GitLab network view was apparently much more useful than the Github network view.
GitLab just needs to work on the little things and they can really be disruptive to GitHub's business.
Another little change that I think would go a long way, is changing the folder icon. I don't know why, but the round corners in the folder icon really irks me. There is also something off about the font that they are using. I think it's just too thick, but I can't really put my finger on it.
However phabricator maintains different "applications" - bugs, repos,etc. so to look at the bugs for a repo, I have to go to the top level, click on Maniphest (the bug tracking "application" ) and go to the project and then click on a bug.
If you don't like a piece of flavor because it's a joke that you don't get or don't find particularly funny, but it doesn't impact your ability to understand or use the software, we're less likely to remove it. We find all our jokes very very funny and cherish each of them dearly.
(If you're committed to removing flavor on grounds of taste, we might be willing to accept changes which replace our objectively very very funny jokes with even better ones.)
Question: has anybody used hosted Phabricator for hosting their git repos (as well as bugs, etc.) ? How would you compare against github and bitbucket. Really seriously considering it because we can move to our own install very easily. But not sure what people think about it. I'm particularly interested in triggers and hooks (e.g. sending an email after commit, posting to bitbucket,etc.).
Continue by ignoring this document and complaining about a
joke that you don't think is very funny with Contributing
> If you prefer a more straightforward tone, you can disable most of the flavor by turning on the phabricator.serious-business setting in the Config application.
Development done right.
An incomplete list of projects using it, some of them VERY large:
- Blender (https://developer.blender.org/)
- LLVM (http://reviews.llvm.org/)
- Haskell (https://phabricator.haskell.org)
- Wikimedia (after lots of discussion and a lengthy selection process, https://phabricator.wikimedia.org/)
- FreeBSD (https://reviews.freebsd.org/)
- Fedora (in some places, for example: https://phab.qadevel.cloud.fedoraproject.org/)
- Khan Academy (https://phabricator.khanacademy.org/)
- Enlightenment (https://phab.enlightenment.org/)
- KDE (https://phabricator.kde.org/)
- Freedesktop (https://phabricator.freedesktop.org)
- lighttpd (https://review.lighttpd.net)
- Kolab (https://git.kolab.org/)
Wikimedia hat lots of content about their choice and the migration process: https://www.mediawiki.org/wiki/Phabricator/FAQ
Phabricator has been in use as a production tool for years and it shows. It is much more sophisticated in terms of workflow and real-world use than alternatives.
Both were first released in 2011.
Gogs is a lot more lightweight and faster than GitLab is. Our previous GitLab instance (7.X version range) used over 1.7GB of RAM (roughly 15 repos with 3 users) and always took longer than 1 second to serve a request (commit browsing was really bad, >5 seconds to serve such a request) while our Gogs installation uses 15MB and always serve requests sub-second. Both ran on the same hardware, with RAID10 SSDs.
Definitely worth checking out if you want a self-hosted, lightweight & performant Git remote solution.
Drone officially supports Gogs as well, so that's nice.
In general I wouldn't consider performance with GitLab an issue and denote it as a selling point for Gogs anymore - it would just be nice if it no longer felt like a Ruby on Rails website...
A optimized site of mine with similiar complexity and database setup has a response time of 16ms and an "onload" event after about 400ms (using PHP-FPM 7 & MariaDB). ;)
Gitlab CI is great if you don't need dynamically provisioned build slaves, for which I found no integrated support. In general, Gitlab CI is much more straightforward and easy to use than Jenkins.
Jenkins wins when it comes to stuff like build artifacts (getting these out of Jenkins is easy peasy (just wget them and provide basic HTTP auth if needed), but with GitLab I have not yet found a way to automatically download say the latest build results), credentials management and other "more enterprisey" features.
Jenkins is easy to install on Debian-based systems; I have no real experience in setting up Gitlab other than via the official Docker images, which is nearly as easy as typing `apt-get install jenkins`. Setting up CI runners/instances is easy as well (apt-get install + one or two calls to gitlab-multi-runner).
Overall I'm pretty happy with Gitlab CI. Especially the fact that every developer in our company can take advantage of automated builds by just enabling CI support and putting a .gitlab-ci.yml in the repository is great. Over are the days were admins had to manage Jenkins jobs.
But programatically pulling artifacts from gitlab CI does not seem to have a well-documented approach.
It's sort of annoying to have to add on another system to the pipeline, but I think it's generally reasonable. Managing artifacts shouldn't really be part of the CI system anyway, I feel it's better to handle that stuff separately.
nginx then serves them under a unique path.
I would very much like to see gitlab offer the ability to get artifacts via some API so I can remove all that hackery.
At this point I want a similar setup for my personal projects, but didn't feel like running a dedicated EC2 box just for a GitLab instance, so I've been using Bitbucket to host free private repos instead. What are others using to manage their own private repos?
Edit: I wasn't aware GitLab.com offers free private repos too. Even if, "Right now GitLab.com is really slow and frequently down."
Can you elaborate on the monthly uptime in reference to the quote on the GitLab.com page?
> Right now GitLab.com is really slow and frequently down.
"The rsync to *Azure* SSD got interrupted last night
when we had an outage. Restarting it now." - 18th Dec
"This means service will partially restore over the next
few minutes and then go away again once the *Azure*
restart command succeeds."
"Looks like we are headed for the ‘double restart’
scenario. The NFS server came back on its own but
*Azure* is still busy restarting it."
"*Azure* restart of the NFS server is in progress"
"Depending on whether the machine is stuck or already
rebooting. No way to tell with *Azure*."
"*Azure* CLI restart of the NFS server finished, that is
usually a good sign."
"We are experimenting with copying data out of our
current *Azure* storage account. Unfortunately the
copying affects http://gitlab.com" - 1st Dez
"Azure incident quote: Network Infrastructure and
Storage - East US 2 - Partial Service Interruption
[East US 2]" - 11. Nov
"Seems to be a major @azure outage..." - 11th Nov
"At 18:00UTC we will start migrating PostgreSQL to Azure
Premium Storage gitlab.com/gitlab-com/ope… , expect 15
minutes downtime." - 10. Nov
"trying another Azure restart of the NFS server " - 6th Nov
"In the last 24h, we had two reboots of our Redis server
seemingly caused by Azure (no kernel panics) and VHD
read errors on the NFS server" - 5th Nov
"Azure are sponsoring us so we are saving a lot on our
hosting bill. We are documenting the move on an upcoming
blog post." - 16th Oct
Their current SaaS is simply not up to standard and it will be hard for others or business to trust and run on it. They should instead run GitlAb SaaS like a proper business.
I can't seem to tell how to find logs.
The example you linked is much better thanks.
Perhaps we should be using a wiki or some other system, but I'd really love for some more enhancements to code review.
As far as commenting on HEAD, I think they've intentionally avoided that given how fast it could change and not having a deterministic way to anchoring comments to the correct lines.
Related: Tom Lehman from Genius explains some of the problems of fuzzy annotation anchoring in a 10-min video: https://www.youtube.com/watch?v=FJyqfRcyYIQ.
Really love that they have free private repos though.
I also make heavy use of GitHub's issues/milestones system, even on private repos, to keep myself organized. I'd probably use GitLab a lot more if I knew of an easy way to port issues and milestones over to GitHub when I decide to make a project public.
On a related note, can anyone recommend some good external issue tracking systems that integrates well with both GitLab and GitHub?
I'm reading the comments on HN and top comments are suggesting competitor products that fix mostly speed and UI concerns.
I've been following GitLab since 3 years it was really cool to host my own GitHub ( back then the design was almost identical ), but now it becomes more obvious how important it is to choose a language before you build a web application.
I think the ruby part was the only bad thing that they shouldn't have copied from GitHub. Also I bet you just can't use a web-app as big as gitlab on your own DO 10$ box and don't have any problems very soon.
If I was part of GitLab team I would definitely put on the table a plan to decentralise the services from their main ruby repository and use something modern micro-service based solution with it's top performant language.
We had CI as a separate application but it ended up being better to integrate it.
It's a small auth layer with only a command-line interface (usually used over SSH). Single python script without fancy dependencies. Used at the university department where I sysadmin.
It can be tested locally with super simple setup (just call once with --init to create a basedirectory). I'm grateful for feedback.
They do so many good thing thus it's hard to complain. But Pages-EE-only makes no sense imho. The blog post even mentions open source projects needing a static web page. But do (small) oss projects have the funding to buy into EE?
A quick integrated project website could be especially helpful for smaller projects were one doesn't want to setup a proper site.
Must be hosted locally for boring corporate reasons.
It would be awesome if they had hg support, but I assume it would require too much. Kallithea is supposed to be the one with hg support, but hmmmmm.... maybe it wouldn't be so much work to put hg support into gitlab instead. I'll have a look sometime.
That's it. I'm pirating GitLab EE.