You can self host it which is cool and means that if the company's funds dry up and they stops development (hopefully never), you can continue using the product. With Google Code shut down and Github losing 66 million in 9 months in 2016, it's an important question to ask about where you keep your source code.
Featurewise, I haven't noticed anything that I can't use Gitlab for that I wanted to do. The interface is still less familiar to me than Github, but that seems to be a function of it being changed relatively often as well as the time spent looking at it.
I also like how much Gitlab embraces open source. They recently acquired Gitter and will open source it. Even though I mainly just use it as an alternative to the still more popular Github, I'm considering picking up one of the Enterprise plans to help ensure the development pace continues like this!
I've only noticed one: the ability to do less. Along with its excellent improvements over the years, it also gained some staggering RAM usage.
It used to be really nice for self-hosting your own private GitHub alternative on a little VPS or RasPi, but those days are apparently behind us.
Being able to comfortably host a limited version of GitLab for a small team on the lowest tier of Digital Ocean or EC2 instances (<512MB) would be a game changer in terms of the accessibility of GitLab as a product. It would give you access to the long tail of potential privacy-conscious users who would like to avoid hosting their code on a SaaS service (and thus wouldn't be already captured by the market leader, GitHub), but might be put off by the high operational costs involved with self-hosting a GitLab instance compared to some of the lighter weight alternatives.
It's entirely possible that a single Puma process may end up using more memory than a single Unicorn process, so the only way to know for certain is to measure the difference.
As listed in https://docs.gitlab.com/ce/install/requirements.html the minimum is 1GB "1GB RAM + 3GB of swap is the absolute minimum but we strongly advise against this amount of memory. See the unicorn worker section below for more advice."
Most of the memory for the configuration of 4GB we recommend is to run extra unicorn workers https://docs.gitlab.com/ce/install/requirements.html#unicorn... You would save this memory because you can multithread one worker.
It doesn't have a pretty interface, but it works, and its requirements are minimal. I've had good success using it to host student repos in my classes for about 4 years.
Gogs is fine.
People, for whatever reason, think devs have to continue adding more and more features otherwise they see the project as "dead". It's not.
In my opinion the Gitea folks are creating a bloated version of Gogs. YMMV.
He was also totally ok with the fork to gitea.
Gitea exists so that more features can be added faster, not necessarily keeping the code quality ideal.
For many more features I use gitlab. With gogs I'm looking for simplicity.
GitLab.com subscriptions https://about.gitlab.com/gitlab-com/ are more recent but this is growing rapidly.
I'm leeching on gitlab.com today, but not enthused about it, if only because I've become disillusioned with GitLab itself.
I pay for email, and I'd be willing to pay for code hosting, too, on the following conditions:
- it's running something like Gogs/Gitea instead of GitLab
- whatever software's on the backend, my subscription needs to allow me to choose the community edition, not some enterprise version
- priced at XX/yr instead of X/mo
Even ignoring that, telling someone their product isn't what you want and to please offer a different product isn't an outlandish thing to say.
I understand I risk looking like an idiot but did you mean X per user per month? If not, what's the difference?
The difference between XX/yr and X/mo is that the latter is a tactic that relies on perceptual psychology to downplay the cost, same as when you see something priced at $3.99 instead of $4. It might be important to clarify that when I say XX/yr what I mean by XX is ~50USD. That's a reasonable price for a small instance (especially since the current going rate for something comparable is $0). Something priced at $8–9/mo, however, costs twice as much, even though the monthly pricing scheme helps to hide it. If you're buying hosting for your code, you don't really need the flexibility of monthly pricing. (What're you gonna do, spin up some short-lived instances for as long as you need them and then shut them down when you're "done" with them? No. The expected user model for code hosting is one that's cumulative.)
Side note: charging per user per month for a hosted instance would be pretty arbitrary, anyway. Put a cap on instance size, workload, number of simultaneous requests, and daily or hourly data in and data out, not on number of users. Charging by the user for a hosted instance is very nearly unashamed rent-seeking. The only reason it makes sense for GitLab EE is because it's on-prem.
I can't help but think of the old "what are you trying to optimize for?" question though. Gitlab.com is OK for me because I don't make money writing code so I'm OK just getting free private repositories and any ci stuff I get is just gravy. I used to think "how will they ever make money?" and this makes sense.
I read this other story about how a DNS service was getting rid of its free tier because the free tier users can't convert. I think gitlab and github have found a good opportunity by giving away free service to free and open source software which means people will have experience using the service and might just keep using it at work (haven't checked but I'm sure github enterprise is not cheap).
I am a GitLab reseller and offer a 10% discount to HN users.
I'm glad that Gitlab exists, however the lazy person in me sees no immediate need to use it. Even if all Github datacenters are destroyed by an asteroid, copies of repos I care about will still be around in enough people's computers to be able to recover.
But anyway, the same argument could be made of an asteroid hitting your own datacenter with self-hosted GitLab instead.
You still have a git repo on both github and bitbucket, even if they stop development you will be able to download your code and host it anywhere you want. No?
You can take a look at some ongoing performance-related issues at https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf... as well as some already completed improvements at https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf...
There's also a plethora of ongoing efforts on making our hosted instance GitLab.com even faster. Lots of issues to look over at https://gitlab.com/gitlab-com/infrastructure/issues?scope=al...
Their real-time updates like the pipeline completion signalling still has some lag. But I think the plan to improve real-time updates is on the roadmap for a big overhaul.
In my opinion, they're doing everything right here. They're not changing designs because some designer disliked the color or popup animations. They're arranging their functional components to align with what they're finding (experimentally) is most usable for their user base.
I don't know whether this comes off like I'm complaining. That's not what it's supposed to be. (I actually liked the [original] redesign announced over the summer.) I'm just here to explain what I saw.
We are never done. We will always be iterating and improving. Much of the feedback we received confirmed assumptions we already had but wanted to test, such as collapsing the navigation, improving breadcrumbs, etc. Other feedback was new and we were challenged to solve those. Everything that was added to this release will undergo a round of user testing and be subject to iteration.
It does not sound like a complaint at all @carussell, thanks for the feedback.
Edit: Do the images in the earliest post display for others? I see image missing placeholder icons.
EDIT: It looks like the images are attempting to load from an old Wordpress blog which is no longer around, with a quick search I couldn't seem to find anything with similar file names in the current website repository :(
Please see below the ongoing discussion:
this should absolutely be a feature in EES. i can't justify the $7,200/yr for just that feature, i'm sure my two product guys could, but the rest of the team is indifferent. apparently only organizations with 500 or more users can benefit from this feature.
I've wondered a lot about whether they would accept MRs into CE which implement a feature that they ship in one of the EEs
We think Kubernetes is the future operating system and we'll continue to add features specific to it. But we realize that only a few organizations are using it today. If you don't have Kubernetes you can still use parts of Auto DevOps, such as the Auto Code Quality.
You can see some of the issues tracked in our GitLab.com infrastructure issue tracker here: https://gitlab.com/gitlab-com/infrastructure/issues (for security reasons not everything is visible to outside users)
Recently, I added a webhook that takes all our GitLab pushes and parses out JIRA information and automatically handles that sort of business-level logic (issue handling, visibility, etc.), which means I spend less time boring myself to death in JIRA. It's just one facet of what I appreciate about GitLab.
Have you found a good solution for auto-linking to JIRA tickets from GitLab comments/commits/etc without turning on the the included JIRA Integration? I want to continue using Gitlab's native issues, and the included JIRA integration replaces the native Gitlab issues with JIRA tickets, which is such a colossally boneheaded idea.
As of GitLab 9.4, you are able to use both JIRA integration together with native GitLab issues. If JIRA integration is configured inside your GitLab project, the issues menu item in the navigation still goes to native GitLab issues, and you can use GitLab issues as usual.
I've been a fan of GitLab for a while, and I like how they continue to iterate and improve it. As far as being a full suite for software development, GitHub and BitBucket can't match it. GitLab seems to be charging ahead faster than the others, and for that, I salute them.
I don't think this will be out anytime soon TBH.
They say you can change the theme but why not make the default grey or white instead of that awful indigo? And they do not allow a default theme from the admin section (that i could find).
Im also slightly concerned about the feature creep here, I love that they try out new devops and CI tools but I wish you could get just a stripped down interface and turn the features you want on and off. The UI is becoming cluttered and the RAM usage is climbing because of it - not everyone is running hot-rod servers and a huge dev team!
Besides that good work and thanks for having a community edition, it keeps small teams like mine alive!
Gitlab can be fully installed as one Docker container, plus a second container if you want a CI runner (although, to be fair, it took me a while to make them talk to each other). Upgrading Gitlab is just starting a container for the new version with the old one's data. TFS is... not as straightforward.
Also we couldn't push enough performance out of it, even on it's own VPS. Once you have 50+ devs pushing to TFS it just gets slow as dirt. Some 5kb commits would take 3-5 minutes.
From my own experience, I don't suggest it as I don't believe it is a well polished or reliable product.
We switched a large Nodejs project from TFS to GitLab and it's been night-and-day on our productivity.
I meant TFS + Git , the lastest TFS is TFS 2017
Meanwhile, the critical feature for me is a easy-to-write and easy-to-read history of discussion on a work item. This is nascent in VSTS. The description and discussion blocks don't even support markdown; The description box has its own WYSIWYG editor, the discussion block barely supports linking to work items(but http links aren't recognized, which makes it awkward to link to e.g. the code or the wiki). File attachments go in a separate tab, so it's difficult to contextualize what part of the discussion they are for.
Speaking of the wiki, it was just introduced and it's pretty basic. For some reason you can only place attachments in a single special directory, which makes editing it through the repo annoying - I want to colocate my pages and their images/attached files, like you would do normally...
I also have some minor quibbles like the stupid iteration workflow(add iteration to project, go to team, select project iterations for team...talk about optimizing for the edge case).
I think VSTS should really replicate the github/gitlab/etc issue description and discussion page. Past that, they seem to be pretty good at keeping feature parity(the pull requests are nice, the CI is okay).
After last change, can't remember which version since it already few month ago, I leave for gitea.
Too many times my co-worker asking for location of x in menu. Where is X, where is Y
It lacks in user base (which might not matter for internal use) and performance and reliability. It can be slow and it goes down occasionally. It hasn’t been enough of a problem for my company to move back to GitHub.
These observations only apply to the hosted GitLab.com, as I don’t self host I don’t know the differences there. I have both public and private personal projects as well as private company projects on it.
With Gitlab you set up a runner instance with their CLI and you're good to go.
Perhaps that's unclear, but as of 9.5.x you can assign an issue to multiple users, but you can only assign a merge-request to one user.
Being able to assign a merge-request to multiple users would be very useful..
It's not quite as polished as github yet but with their recent funding round I would expect gitlab to pick up steam and close the gap even further. For day to day use I'd say they are now at 95% feature parity or even better, and in some cases it is actually ahead.
I still switch between Hub and Lab, but seeing GitLab's growth makes me smile.
I personally think GitLab is hungrier, and have some really great features, but I haven't had any contact with their support to know if something goes wrong that one can get unstuck quickly
Other than that, for casual use, they are all excellent products