Hacker News new | comments | ask | show | jobs | submit login
GitLab 8.3 released with Auto-merge and GitLab Pages (gitlab.com)
196 points by doppp on Dec 22, 2015 | hide | past | web | favorite | 101 comments

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

[0] http://phabricator.org/

[1] https://secure.phabricator.com/book/phabricator/article/hera...

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

We used GitLab for a few months, until we could get spending approval for Github.

The switch was surprisingly controversial, as the GitLab network view was apparently much more useful than the Github network view.

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.

Ack, OP is talking about Phabricator vs. GitHub though. For anyone wondering.

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.

Opposite for me. After using Phabricator for a while, the GitHub issue tracker feels so primitive.

+1 just because of this


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 like the "next step" at the end of the documentation.

    Continue by ignoring this document and complaining about a
    joke that you don't think is very funny with Contributing
    Bug Reports.

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.

Yes, it does. It's called Harbormaster.

Setting up jenkins takes like 10 minutes :\


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

Development done right.

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.

It's much better suited for open source projects than GitHub, not only due to the powerful issue tracker and other community features.

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.

It's interesting to see which projects have experience with naming servers (anyone who didn't include "phab" in the name)

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

Facebook uses it for some open source projects: https://reviews.facebook.net/

>a more mature alternative

Both were first released in 2011.

I assume Phabricator was in development way before that inside Facebook but I'm not sure.

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.

[0] https://github.com/gogits/gogs/

[1] https://github.com/drone/drone

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

Glad to hear performance got better in 8.x. What can we improve to make it feel better?

Less memory usage.. I went from gitlab to gogs because of that.. 2gb usage while idle..

Thanks, we're working towards a multithreaded application server to reduce memory usage https://gitlab.com/gitlab-org/gitlab-ce/issues/3592

Same here. Switching to Gogs saved several GB of memory, and it's much faster.

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.

Getting artifacts into gitlab CI is pretty straightforward.

But programatically pulling artifacts from gitlab CI does not seem to have a well-documented approach.

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'm still using the old approach, which is adding a local directory as a docker volume, where all my artefacts are stored.

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.

We're working on an artifact browser for 8.4. I assume an API for that will be trivial after that has landed.

You can follow the work in this in https://gitlab.com/gitlab-org/gitlab-ce/issues/3426

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.

Definitely a huge fan of GitLab, best open source solution and super easy to host locally.

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.

I am curious about this as well. Is it a feature that has seen widespread adoption?

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


Disclosure: I work at GitLab. Have you looked at using our free hosted SaaS GitLab.com with unlimited repos and collaborators? Thanks for using CE!

Thank you! Somehow I completely overlooked that page.

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.

https://twitter.com/gitlabstatus on https://status.gitlab.com mentions Azure cloud several times.

  "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?

We moving to metal on Softlayer. See https://gitlab.com/gitlab-com/operations/issues/14

Thanks for the info. All the best with the transition to IBM Softlayer.


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.

IME there's only an hour or so of downtime each month.

Hey I am browsing some of the CI examples and this is the first one I saw


I can't seem to tell how to find logs.

The logs are normally on this page. In this case there is no log, probably due to an error (this build is 4 months old). For a better example see https://gitlab.com/gitlab-org/gitlab-ce/builds/485077

Ah ok. It was unclear from the UI that old logs are archived.

The example you linked is much better thanks.

You're very welcome.

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.

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.

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.

[1] http://gitolite.com/

What about hosting them on gitlab.com?

AWS CodeCommit is another option.

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'm also trying to use it more often, but I have to admit that it is significantly slower than GitHub.

Really love that they have free private repos though.

gitlab.com really is awfully slow, but I don't know how that reflects on smaller deployments.

Only .com is slow and we're working on it. Local installations should be fast.

Seems to work well on local servers at least.

What's the "Network effect" for private repos?

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.

Just because a repo starts out private, it doesn't mean it has to be private forever.

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?

Congrats on the team.

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.

Another plug:


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.

title should be: ... and Gitlab Page (EE only!)

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.

Why can't you use GitLab.com with CI? You can bring your own runners if you want.

Missed that, in this case it should work.


gitlab.com is EE and is free to use. If you self-host gitlab then surely you can serve static pages as well.

All I want is a Kanban board. It seems I have to fork out $$$ for JIRA. :(

Please see https://about.gitlab.com/applications/#scrum-boards for the options with GitLab. There is also work done to redeem a bounty for GitLab support in Huboard.

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

Phabricator has a Kanban board. It's also a fine replacement for JIRA for many use cases.

Anyone knows if there are plans to support hg-git and hg on Gitlab?

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?

GitLab Pages (EE only)

That's it. I'm pirating GitLab EE.

Url changed from http://venturebeat.com/2015/12/22/gitlab-just-launched-anoth..., which points to this.

Thanks dang!

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact