Phabricator[0] is a more mature alternative if anyone is interested in an open source and free substitute for GitHub. I think the only thing GitLab might have over Phabricator is a familiar GitHub like UI. Phabricator was an internal Facebook project that was open sourced. It's actually far more than just a substitute for GitHub. It has a much better system for managing issues, and better code review tools as well as other powerful features. My favorite feature is the herald system[1].
Phabricator is a very good tool! But calling it a substitute for GitHub seems a bit off. GitHub (and GitLab) revolve around repositories. As the name implies they are focused on git and git workflows. As a user you are using `git` most of the time when interacting with the systems.
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.
It's a fine substitute for GitHub. Both are source code and project management tools. Just because they have different user interfaces doesn't meant that they don't solve the same problem.
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:
I just can't get into Phabricator. Babel switched to it for issues. I find it hard finding anything. I kind of wish they would mirror the issues on to Github.
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.
No it's not just you. I find it hard to explain but GitHub does have the right amount of white/empty space to make consumption of information easier. I've always hated the simplicity of GitHub's layout, but after studying their commits and branches pages for my product, I've grown to appreciate their simplicity.
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.
Agreed. I just signed up to try out GitLab and went to browse GitLab's own source code to see what they were using. First thing: Rails, clearly. Second thing: Holy crap, I have to scroll this much on my laptop to browse their project? The amount of whitespace is bonkers. A bit of googling tells me that they made this change a few months ago with GitLab 8.0, but the bug report about the whitespace seems to have been ignored.
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?)
I don't disagree with GitLab's network view being more useful. People also shouldn't assume GitHub isn't fallible with their decisions. The fact that it took, I don't know how many years for them to implement side by side diffs is living proof of this.
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.
I was commenting more on how there is a hidden element that GitHub has, that would explain why the person that I responded to would feel he/she was looking at a wall of text. I used GitLab and GitHub's branches page as an example, since I studied both quite a bit and it was easy to highlight how sparseness has it's advantages and how it can shape ones perception.
the other issue with phabricator is workflow. The way I think (and most other people) is on a repo basis - all bugs, reviews, wiki is contained within a repo level.
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.
very unintuitive.
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.).
I've never actually heard of this, thanks for the links. We use gitlab at work but I took quick browse of this site and it seems pretty cool. Does phabricator have a CI server out of the box that's easy to use? One of the major draws to gitlab recently (at least for me), is a CI server available to the projects for free.
> Phabricator includes applications for: .... counting down to HL3;
> 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.
I'm also a phan, but phabricator is more complex than GitLab and doesn't have (to my knowledge) a free, hosted version like gitlab.com. It also isn't quite as appropriate for open source projects, in my (admittedly somewhat limited) experience with it. I really do love differential though, and its UI is very cohesive.
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.
Note that not all of those use Phabricator as a bug tracker (KDE, lighttpd, LLVM, Haskell, I imagine a lot of bugs for Wikimedia are reported through project chat pages on the wikis themselves).
I've been using GitLab before, and use it from time-to-time still, but I've moved over to a self-hosted Gogs[0] server with Drone CI[1]. Both projects are actively maintained and both runs super well in Docker. Gogs is almost an identical clone of GitHub, although some small parts are missing but will most definitely be added in an upcoming version.
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.
Just wanted to add that we're working hard to bring down the request time in GitLab 8.x. We're not there yet but already optimized a lot of SQL queries and this release added support for better comment caching to prevent markdown parsing. Edit: we had to revert the comment caching at the last minute due to a bug but we're working on that, many other improvements and performance monitoring with InFluxDB and Grafana
I can definitely confirm that somewhere around the 8.0 release (I forgot when exactly) GitLab got a lot faster in general. Previously with the 7.x line it took about a couple seconds at least to load a page but now I barely get over a second until "onload", with response times of about 400ms.
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). ;)
I'm a huge fan of Gitlab and use it at my workplace, but haven't upgraded to even 8.0 to try the continuous integration (CI) feature. Wikipedia makes it look pretty comparable on features to more mature CI system like Jenkins but can anybody here say how the current CI in Gitlab 8.x really compares?
[We're running a Gitlab instance and one CI instance with multiple CI runners in the Google Cloud.]
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.
I sometimes have a similar issue with Travis CI, if I can't use one of their built in integrations or something. A simple workaround is to just upload an artifact to S3 after a successful build. Then on another system scan the bucket with a cron or listen for an S3 event notification for further processing. You can put a lifecycle policy on the bucket so it cleans up after a while too.
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.
I gotta say, this is one of the killer features (for me) of gitlab. It's very actively maintained and constantly improving. (Nice to see that Mattermost is included automatically too, gonna have to enable that later and mess about with it!)
shouldn't your build tool do that? If your build creates artifacts, I'd imagine you'd want to store them in an artifact manager (Nexus, Artifactory, etc) or deploy them.
We working on an auto scaling Runner for dynamically provisioned build secondaries. This uses docker machine so it works with most clouds. It will most likely land in 8.4 but we're not sure yet.
Gitlab CI is absolutely fantastic. I have a CI runner running on a Raspberry Pi under my desk and that thing just keeps running build jobs. The runner itself is an application written in Go that can run job locally or in a docker container.
GitLab CI has been hard to use for a long time since we didn't devote a lot of time to it (less than 1 person). But we saw it got traction nonetheless and opted to integrate it in the main GitLab application in 8.0. Since then it's popularity is growing fast, we added a lot of features (most recently build artifacts) and we have more than 2 people working on it full time.
My startup has been using GitLab Community Edition for 3 years now and we're really happy with it -- especially the code review features. We've also started using the CI in the past few months.
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."
"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
There have appearently been really big troubles, starting in November! Is Azure cloud that bad or is it a problem on your side? What about moving to AWS/Google/Rackspace?
Like I said to GitLab numerous time, GitLab should split ( or go back to ) their original Gitlab.org and Gitlab.com
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.
We're very aware that the current performance of GitLab.com is not acceptable. This is caused by its fast growth and we're working very hard to improve it in the coming months. Yesterday we migrated to all SSD storage, which is an important step.
Interesting. What do you like about code review things? I personally found it to be lacking. It's hard to dig up comments on branches that have been merged into a master branch and I'd also like to have notes/comments on the HEAD of a project. Right now, they just get perpetually buried. That's where a lot of project decisions end up getting made in my team.
Perhaps we should be using a wiki or some other system, but I'd really love for some more enhancements to code review.
I agree with you on finding branch comments post-merge. I found using merge requests makes it easier, but to be honest, I don't look at comments much after the fact. Making more small branches with merge requests was really helpful for us.
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.
I just use gitolite [1]. I have the smallest droplet you can get on DigitalOcean, and it hosts my website along with gitolite and a couple of very small CI jobs for personal projects. There is no cool web UI, but I'm fine with that.
GitLab has a fine interface and offers free private repositories. If it weren't for GitHub's network effect advantage, I'd use it for all my git projects.
I'd imagine the network effect is non-existent for private repos, but for public repos it's huge. And then there's the issue of switching between Gitlab and Github for private/public projects.
That's essentially it. GitHub has won its role as the (meta)repository of public record. I suspect many stick with it over its competitors for this very reason.
Exactly this. I generally begin my projects as private GitHub repos and then make them public once they have a MVP-quality demo of some sort.
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.
A $10 DO box should run GitLab fine for a couple of people. Many of the speed concerns are about GitLab.com which are not due to ruby but the file server (we just moved to SSD and are working on decentralized storage). To make GitLab faster we're using Go were it makes sense, see the part about workhorse in the release announcement. We're very happy with using Ruby and Rails for the complex business logic. It allows us to ship many new features every month.
We had CI as a separate application but it ended up being better to integrate it.
I'm also not a huge fan of them moving the menu to the left as opposed to leaving at the top, like github has now. I just find it more natural at the top.
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.
GitLab.com runs EE so you can set up a free site there. We have free shared runners too so you don't have to configure a thing. I set it up yesterday for Sytse.com (with a redirect, cname support coming next month)
Thanks for replying. gitlab.com is not an option in my case a.o. reasons due to ci testing (which btw is supergreat in 8.x!!). But this pages ee is the first time i think gl did 'wrong'. Not really 'core-essential', but a pity.
Thanks. I should have mentioned that I have seen that. I tried GitLab Kanban, thinking the product created by the same organization as GitLab would be the best. I was dissatisfied at installation time (uses Docker, in contrast to the RPMs provided for GitLab CE) and stopped there.
Must be hosted locally for boring corporate reasons.
Thanks for the feedback. We're considering bundling a kanban board into the GitLab Omnibus packages to make it easier to install, see "Software to ship in the Omnibus packages" on https://about.gitlab.com/direction/
If you're happy with something hosted, check out https://trello.com/ - it doesn't have the complicated workflow-defining things Jira does, but that's not always a bad thing, and it starts out free.
I've been an avid user of Trello. Easy to use, very simple for any external stake holders to get into (and nice permissions) while being super simple to use. They've got a great amount of 'example' boards as well: https://trello.com/inspiringboards
You don't need any special support on the gitlab side for hg-git, since that's all client side.
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 is what I thought, till I tried to clone a git repo using hg-git interface. Don't remember the error I got, but that did not work for me. Maybe someone here has experience making this combination work?
[0] http://phabricator.org/
[1] https://secure.phabricator.com/book/phabricator/article/hera...