Maybe with this 4M they can stop producing workflow crushing bugs. I'm getting a bit tired of explaining to my boss why first he can't search the code because our repo is too big, then search doesn't work in firefox, then when he gets through the diff/file is too large (we've only recently seen the syntax highlighting start to work too).
Then after someone does the work, then they can't assign the MR because of glitchy privs!
If anyone is reading this at gitlab, please don't take this personally. I wouldn't leave gitlab, I just need the core 80% of the functionality to work flawlessly, and my upgrades to work without half of my team moaning at me for having faith that this upgrade will be the gold edition we need.
Also like most people that I've spoken to, we're not interested in gitlab-ci at all (we already have a ton of buildscripts in jenkins). If we didn't like jenkins we'd be using stash/bamboo right now.
I'm sorry to hear you're workflow crushing bugs on updates. We'll certainly use the money to hire more developers and service engineers https://about.gitlab.com/jobs/
Although GitLab moves very fast and there always are regressions I thought we are getting much better at releasing patches for all regressions. I'm sorry to hear your experience is different.
How large is your repo? Code search shells out to git and that should be very performant. Are the repositories stored the same server as the application runs on?
Syntax highlighting switched from pygments to rouge, ensuring we don't have to ship Python anymore.
I didn't hear about the problem of assigning the MR, can you link to an issue for that?
We think that the CI configuration should be stored in the repository and that Travis and GitLab CI are the future instead of Jenkins and Bamboo.
We understand that not everyone will use GitLab CI (most enterprises are using Jenkins) but already have many organizations (including some very large ones) using GitLab CI in production. GitLab CI will undergo massive improvements after integrating it into GitLab itself in 8.0 so you might want to stick with Jenkins if you don't want to be surprised. But we recommend anyone to give GitLab CI as spin while we keep adding features. You'll be happy to know that GitLab 8.1 will ship with a commit status API that makes integrations with third party CI tools easier.
You've gotta look at it this way - when github updates do I even notice? Have you ever had a bug that stopped you working on github? I personally use github all the time and have never seen a bug on it. I trust it completely (well.. tech wise).
Our repository is a few million lines, maybe 20,000 commits. The search works fine now it has been changed to call out to git properly (aside from the js searchbox thing in ff). Repositories are stored on the same server. I'm not going to dig up all the issue numbers and turn this into a support request, I am involved in reporting these and commenting on them @ gitlab.com.
The syntax highlighting updates have been very well received, but I mean gitlab was shipped with syntax highlighting that doesn't work properly with Java code. Not exactly a unusual lang. And I guess that's where my rant was going - you can't ship crap like that, you should be shipping with 0 known bugs. Every time gitlab ships a bug like this, I take a knock in the office on your behalf and that's why I'm so openly annoyed.
Perhaps you could do a LTR or open a beta programme for early adopters?
I'm glad to hear most things are working now. We're hiring to put more eyes on the open issues on GitLab.com. If you want a more stable GitLab upgrade to a new minor release on the 21th of every month. At that time all the patches should have landed. We strive to fix all known regressions. If they want to use the bleeding edge people can use our release candidates. Or run master, like we do on our internal server.
> Also like most people that I've spoken to, we're not interested in gitlab-ci at all
Consider me part of the crowd that is very interested. Travis is atrociously bad. Jenkins I've heard some good things about but I have mostly negative experiences with it. Alternatives are needed. And something like gitlab would sorely lack if it didn't have CI integration.
We are definitely interested as well.
- Open-source (check)
- Self-hosted (check)
- Integrates with GitLab (check)
We do run Jenkins currently for some projects, but nobody is really happy with it. Sure, it gets the job done, but not the easiest software to work with.
That's how we do it. EnvInject and shell scripts. But I'm starting to think Jenkins is a bit much to run the equivalent of "HOST=somewhere NODE_ENV=production ./script/deploy" and ping a slack channel
I was using travis-ci for a long time. One day my credit card died during their billing cycle. They emailed overdue receipts to colaborators on all my travis-ci repos. All clients, all devs, everyone. Thats breach of information, I don't want client1 to know who all are employed at client2's firm.
Ok, fine, bugs exists in software. I emailed them saying that 'Guys, you should email only repo owner when payment fails, no everyone on the team". No response. I considered that lack of support and moved to circleci.
Admittedly, when self-hosted some of these may go away, but here are a few that come to mind.
* General awfulness when it comes to packages. Outdated packages. Nonstandard packages. Ubuntu, instead of debian + testing, is a terrible choice for a CI.
* Horrible support for multilingual builds. God forbid if you have Python 3 scripts in your go project.
* With github, force-pushing during a build causes the build to error and travis can't detect that
* Lots of papercut issues in the UI
* There's always something when setting it up on a project that makes me end up fighting with it and figuring out crazy workarounds for it for several hours.
There's a lot more, though most of them have to do with point #1 and their choice of Ubuntu as a platform. I don't remember the rest.
I just went through the same process for my team, settled on CircleCI because the pricing structure fit our needs. We're still newish to CI in general so we might be wearing blinders but it's fit our needs so far.
So this is a little bit "in the weeds" but with the seed round closing back in July for $1.5 million why such a short turnaround for the series A? Is this normal? Considering it probably takes at least a month to close out a round does that mean GitLab went back out to fund raise only a month after their $1.5 million investment?
Not trying to be critical or anything I'm just really curious.
Khosla invested in our seed round and we kept talking with them. They are a great investor so we are happy they wanted to do our A round. So we raised an A earlier than we expected beforehand. We still haven't touched the seed money, in our last month we were cash-flow positive. But I'm happy we did a priced round and can focus on growing knowing we have enough cash.
Congratulations. I was just remarking at work that Gitlab is awesome. It's an open source project that 100% does what it says on the tin; we downloaded and installed, and haven't had to worry about it since.
Agreed. They are a shining example of what I look for in a commercial company building an open source product. Self-hosted, community edition with no fundamental deficiencies, hackable, and a CEO with more 3rd party presence (he's always on here in the comments) than anyone could ever ask for.
I only wish it were written in something which compiles native, like C or Go. Not bad enough to switch to anything else however, and it's really just my own personal dislike for Rails/Ruby.
Love the Gitlab-CI integration too, and am excited to see how it grows/improves over time.
We love the speed of Go. That is why with GitLab 8.0 we'll make gitlab-git-http-server the default way to clone repositories. For CI the runner that executes the tests https://gitlab.com/gitlab-org/gitlab-ci-multi-runner is already written on Go so it is portable and installs without dependencies.
We expect that for the majority of the functionality a high level language will continue to be the best choice. Personally I'm watching Elixir and its Phoenix framework that are very fast. But for the foreseeable future we're very happy with Ruby and Rails.
Switched a lot of personal projects over to GitLab, and been really happy. I'm very excited to see this. My only complaint is the lack of integrations from the rest of the world. It's pretty hard to find good services that hook into GitLab
Note: I'm talking about hooking into gitlab.com not a self hosted instance
We would love to see more support for GitLab.com. Things are moving the right way with https://about.gitlab.com/applications/, also CodeShip is considering support now as are many others. But we have some way to go, please keep telling the services on Twitter. By the way, what integration would you like to see first?
CodeShip would be awesome, I'd also love to see CodeClimate support. I didn't know about https://about.gitlab.com/applications/, I'll make sure to keep an eye on it
I have to say I was wrong about GitLab. I moved my team over to Gogs due to getting various 500 errors with GitLab. Gogs admittedly did feel faster, though I reckon that's due to it having a simpler codebase and perhaps Golang.
Anyway, after discovering the errors I was getting was most probably caused by an insufficient server, I migrated back to GitLab, this time on a much larger instance. It's been nothing but brilliant since.
I tried to use gitlab and was very excited with the self host option. But for a small business, it was too much hassle with setup, installation and the biggest issue: huge memory requirement. On a DigitalOcean droplet of 512MB, it was too slow. I switched to Bitbucket private repo.
I'm not sure it's realistic to expect great performance on a tiny droplet in a budget provider that over-provisions the heck out of these tiny instance sizes.
Spend more than $5/month and you may get better results.
It's actually not so obvious. I run an droplet with email, xmpp, web, several django apps (+postgres), and a few other small things, and don't even come close to pushing the limit on the cheapest DO droplet.
GitLab has actually a pretty large overhead, and for a single user, it requires quite a bit of CPU/RAM. I assume that the requirement is not lineal though.
No, they're not. That said, there is no valid engineering reason why any web app should require more than 512MB of memory to run with minimal user load.
User load is what bumps up the RAM requirements. If the active user count is in the single digits and you're running into problems with RAM, either something is deeply misconfigured on your server, you have a ton of data, or the codebase is poor.
Wow, that's a lot of blanket statements. Nevermind the fact that GitLab won't even have a full 512 MB at its disposal in your particular case (the $5 512 MB droplet).
Memory is cheap. GitLab's resource usage doesn't increase much from the baseline as you go from 1 user to 100 users. You just can't run it on a potato.
An empty Rails app is already 100MB+ or memory. GitLab is running the largest open source rails app. Also, since we use Unicorn instead of multithreading we have to spin up multiple Rails apps.
>That said, there is no valid engineering reason why any web app should require more than 512MB of memory to run with minimal user load.
GitLab (and every other Rails app) makes the assumption that it's better to eager load an entire codebase once at boot time rather than to load code on demand and throw it away during a request.
That trades off baseline memory usage for runtime performance, and it's a perfectly valid 'engineering reason' for why GitLab's baseline memory usage is so high.
I think you're comparing apples to oranges. As far as I know BitBucket doesn't offer a self hosted solution but GitLab offers both. In fact they match BitBucket on pricing too, well at least for the free tier. You can host private repos directly on GitLab and BitBucket for free.
The self hosted option may not be right for you especially if you're already using BitBucket private repos. Why did you not try GitLab's hosted private repos?
I'm curious as to why you didn't simply go with the free hosted gitlab.com option, instead of bitbucket. Both are hosted, and I feel that gitlab has more features (ci, free, and a few small niceties).
I am feeling naive but I have to ask: why GitLab? Is there something it does that GitHub does not do? I assume that I'm missing something but it seems like the big feature here is "not GitHub" which is hard to sell to the higher-ups.
1995: I'm feeling naive, but I have to ask, why Unix? Is there something Microsoft doesn't have?
2005: OMGZ M$ monopolyzzz
Seriously, competition is good. Putting all your eggs in one basket is not. Always keep a copy of Github repo as a Gitlab repo. Learn about git remote-add. Github was DDOSd a few months back, don't let that stop your work.
Mostly I agree except for the bit about Github being DDOS'd "stopping work".
I never understood quite how the same people who were chomping at the bit declaring "git is our saviour" 5 years ago, are the same people who now claim to be "unable to work" because GitHub is not available...
GitHub is not just a place to host Git repos. It has an issue tracking system, wikis, pull requests, integrations with 3rd party tools, and reviews done through a pretty web interface.
If you rely on those parts of GitHub and it gets DOS'd, your workflow suffers.
For reference, GH wiki's are just git repos of Markdown files. You can pull/push just as you would a regular repo.
For the other things: I know the things it offers, and how much certain people get attached to them (as if GH somehow invented simple issue management). I didn't say you can work when GH is offline for a week. If it's down for a few hours it seems unlikely people would not be able to work at all because of it.
Honestly all of this is why I very much prefer open, simple things that can work offline:
* GH wikis are a good example of this.
* BugsEverywhere could be a good replacement for a purely centralised issue tracker.
Some things (e.g. CI builds) are generally likely to need a central repo up to pull from, but in general I believe that if you embrace and rely on open and simple tools, your options to avoid network/vendor related issues are much greater.
I have my own issues with GitLab but it's infinitely more trustable than GitHub, which is not only closed-source, the "Enterprise" edition has vendor lock-in like "Server side Git hooks are not supported by GH Enterprise" - forcing you to use GitHub specific tooling and conventions, on top of the ridiculous fees they charge.
There are 1000+ features open on feedback.gitlab.com, we can't make them all. If people contribute them that is a strong signal they are wanted. What is the feature you would like to see?
Having switched over for a week or two now to a self-hosted instance, there are some major workflow issues we've encountered. Odds are good that some are just undiscoverd features/user error, but:
* Navigation between 'root' project and per-user forks is terrible. There's no way I can see to go from the root proj (where all the issues/MRs are) to my fork.
All the necessary data is available over the API, just not present on in the UI.
* Issue labelling is kinda nasty. You default to no labels for a new project, but you can 'generate' the default set. If you want to add a new label from teh 'new issue' page, it doesn't show up as an option after adding. Make it a modal or refresh teh list or something.
* You don't seem to eb able to search by commit # in the search fields?
* 'merge this MR' button sometimes just arbitrarily fails, and refreshign the page and hitting it again will work (no commits/repo changes in teh meantime)
* No equiv. of the github 'network graph' that also shows other forks.
* It took a bunch of pissing around to disable gravatar which was giving mixed content SSL warnings even though it shouldn't.
* Live preview of teh markdown input for comments/messages would be nice, especially with some apparently odd heuristics for deciding whether to autolink something like a same-repo/file:line type.
* Having read the various docs I can find a few times now, I still have no clue how to set up gitlab-CI on a self-hosted instance.
As I say, some of this is probably just not knowing where things are, but it's not for want of looking.
Please copy GitHub's CSS styles for its markdown files. This may sound petty, but I really think it's part of the reason why open source projects do so well there. GitHub nailed it. It's a pleasure to read compared to the competition's representation.
Obviously copying anything is not possible unless they have a free license.
I agree that GitHub's rendering of markdown files is much better than ours. We hope to improve it. Our first interaction engineer just started and we're looking to hire more https://about.gitlab.com/jobs/
Of course, you're very welcome to submit improvements yourself, as long as you do not submit proprietary code.
They've had this for a while now and is one of the main reasons I ended up using GitLab for some of my side projects. I don't think this is going away I think it's just another part of their business model.
It is, our on-premises income is more than enough to pay for GitLab.com. We might introduce more paid plans in the future but I don't expect you'll ever have to pay for the things we offer for free now.
We run GitLab.com so we have a reference for a very large GitLab instance that is in heavy use. We do offer paid support for it, but there is also a public, free support forum.
Then after someone does the work, then they can't assign the MR because of glitchy privs!
If anyone is reading this at gitlab, please don't take this personally. I wouldn't leave gitlab, I just need the core 80% of the functionality to work flawlessly, and my upgrades to work without half of my team moaning at me for having faith that this upgrade will be the gold edition we need.
Also like most people that I've spoken to, we're not interested in gitlab-ci at all (we already have a ton of buildscripts in jenkins). If we didn't like jenkins we'd be using stash/bamboo right now.