GitLab announces $4M series A funding from Khosla Ventures
about.gitlab.com
about.gitlab.com
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.
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.
I have not. It doesn't look to be open source though, so not self-hostable - my interest stops at that point.
Until it gets basic features like that, Jenkins it is.
* 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.
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.
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.
The advantage being that you can use the same scripts during development.
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 want GitLab to work flawlessly when you upgrade. And at the end of each monthly release cycle the patched version should not contain any known problems. We're working hard in the regression issues to make it so https://gitlab.com/gitlab-org/gitlab-ce/issues/1990 and https://gitlab.com/gitlab-org/gitlab-ce/issues/2297
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.
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?
Not trying to be critical or anything I'm just really curious.
- Money is dirt cheap right now (and won't be for long)
- Investors who see promise and progress in companies typically like to double-down early and often if they can
Makes total sense.
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.
Note: I'm talking about hooking into gitlab.com not a self hosted instance
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.
Well done GitLab!
May be i was not doing something right.
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?
Here you go:
> On a DigitalOcean droplet of 512MB
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.
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.
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.
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.
For less than the price of your $5 droplet, you get 4x the RAM and probably an equal amount of CPU.
Just don't expect much support from OVH because they're busy all the damn time.
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.
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.
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...
If you rely on those parts of GitHub and it gets DOS'd, your workflow suffers.
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.
This will help: http://sindresorhus.com/github-markdown-css/
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.
* 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.
* I agree it is too hard to find forks. https://gitlab.com/gitlab-org/gitlab-ce/issues/2406
* I agree we should make it easier to add new labels to an issue https://gitlab.com/gitlab-org/gitlab-ce/issues/2574
* I would normally replace the full commit sha1 in the url of another commit. But feel free to add it to the search.
* That is strange, hopefully this gets better when we get rid of satellites in 8.0
* Indeed, the graph is for one repo, the calculations are done live and are cached, but doing it for many forks could take too long.
* We load the gravatar's over https by default if you enable https in gitlab.yml https://gitlab.com/gitlab-org/gitlab-ce/blob/master/config/g..., it is strange that you had a mixed content warning.
* Issue comments should have a preview tab.
* The documentation is in https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc... but after 8.0 it will be integrated in GitLab itself so you no longer have to set it up separately.
1. Google "GitLab [obvious feature]"
2. Land on feedback.gitlab.com, on a feature request with hundreds of upvotes
3. "We're accepting pull requests"
4. Filed in 2013
5. Still open
6. Sigh loudly.
7. Check the blog for what evidently more important features they've been working on instead
8. "We're very excited to announce that we'll ship GitLab Mattermost, an open source, on-premises messaging app"
9. Sigh loudly
10. Conclude that they are probably an open source company strapped for cash and to cut them some slack
11. See HN article about closing series A
12. "Oh good, now they can finally get to their epic feature backlog"
13. "I think we're already there, what would you like to see?"
14. Sigh loudly.
Don't get me wrong, I love GL. But wow is that workflow annoying.
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.