GitLab 10.4 released
about.gitlab.com
about.gitlab.com
Please don't go down this rabbit hole, GitLab - there will be dragons (in essence you will have to build an OS for the browser). Developers have their beloved editors that work very well for the most part (at least better than their JS counterparts).
It is fantastic.
I'm so glad Gitlab is providing competition to Stash and Github. Nice work.
As warned against we don't want to fall in a rabbit hole of spending all our time on this instead of the other parts of our complete DevOps vision https://about.gitlab.com/2017/10/11/from-dev-to-devops/ (logs, roadmaps, create project on push, binary repository, incremental rollouts, tracing). Therefore we based the web IDE on the awesome VScode. This means that it is a doable effort to maintain it.
It would be nice to see burndown charts in CE along with EBS[1], just like pipelines and runners.
[1] http://help.fogcreek.com/7676/evidence-based-scheduling-ebs
[0]: https://about.gitlab.com/stewardship/ [1]: https://gitlab.com/gitlab-org/gitlab-ee/issues
It is an argument against the cumbersome Git workflows, and the even more cumbersome GitHub Pull Request workflow on top of that.
Why can't I fix the typo in my editor, hit "upload", enter some commit message and be done with it?
You can do this, if you have permission from the repository and have a local up-to-date clone already. I suppose it would be nice to be able to create a PR to someone elses repo without needing to fork first. I don't see any other reasonable way to make this easier.
Also, at Google, it's not even Git, or a Git/Github workflow.
This was not about whether or not this feature is good for the Google repo (of course it is, nobody disputed that!). This was about whether and how to apply this to other projects.
The comment I replied to was claiming that it was the git workflows (I assume for submitting, but am open to correction) that make this cumbersome. I was pointing out that in an enormous repository (and I did mention my current employer as an example too -- and we use Git, not Google's internal tooling), just getting to the point of having the latest version of some far-flung file that you usually never touch open in your editor is cumbersome enough to make this feature a win, regardless of whether the workflows for submitting the change disappear altogether.
I would still see this as an instance of unnecessary complexity in the Git workflow - mostly the workflow for submitting, but not just that.
Of course, one could also argue that this is by design. Still, I don't see why a lightweight client that is feasible for the web would not also be feasible for the command line.
For example, it would be great to be able to have a checkout with reduced history. You could reduce in time and/or space, i.e. just a subtree and/or just the last 3 months. Even a distributed VCS doesn't need all history and all files as long as it has the relevant checksums.
If you haven't seen it before, check out gitless: actual research-backed simplification of the git commandline workflow.
Reduced views of files and history are super useful, but unfortunately don't work in the case where you've browsed your way to a part of the code that you seldom work on, since you're less likely to have loaded them into your narrow slice: it's still nice to be able to fix spelling mistakes far afield, and the web editing helps nicely for that.
What would help with the cases you describe, though, is a synthetic filesystem view, cache-faulted in as needed, like the one Microsoft is building. I'm pretty excited about where that's heading. https://github.com/Microsoft/GVFS for the project, https://blogs.msdn.microsoft.com/devops/2017/11/15/updates-t... for the announcement they're going to be working with Github. Pretty cool stuff.
"No yak goes unshaven."
Hopefully, GitLab's idea is not replacing your local IDE. It is just for making things easier and we are doing our best to give you the most powerful tool out there. Although, it's currently in Beta state, I believe it's very useful when I want to go and fix a typo or change a simple thing in multiple files and do a quick commit.
One last thing is, please don't forget that, not only developers use GitLab. It's kinda easy for us to checkout the target branch and do some commits but this is a golden for not so technical folks.
Personally, I'm not a big fan of "open core" systems for this reason. I'd really prefer that companies like GitLab concentrated on actual services rather than trying to sell software. Having an "open core" can in some ways poison the core for outside development because you usually have to allow your code in the enterprise versions (or maintain your own forked copy). This is one of the reasons why Ghostscript never got the outside help that it really deserved (let's face it -- who uses a free software system and doesn't use Ghostscript?) The fact that nobody pays for it -- or even contributes -- was at one point a pretty sore issue for the author.
I love the fact that GitLab contributes useful free software to the world. I am disappointed that their business plan relies on selling proprietary software. I honestly believe they would be in a better place if they took a different approach, but they have always very politely disagreed with me when I've mentioned it ;-).
We tried charging for services: donations, paid feature development, and paying for support. None of them scaled and we moved to open core which allowed us to spend much more time on performance, security, installation, and dependency upgrades.
We want to make sure that the open source version of GitLab is just as performant and has an equally good UX as the enterprise version. There is no difference in the UX and there are no proprietary performance optimizations in the enterprise version.
There are some things that we see as a feature but that you could see as a performance item. An example is the SSH lookup in a database that used to be in enterprise and landed in the open source version in this release.
Here is a link to our current CSS Refactor plan which will reduce the size of our CSS significantly and reduce render times. https://gitlab.com/gitlab-org/gitlab-ce/issues/42325.
We've got a lot in the pipeline. In the process we won't be shipping any new features, unless you call blazing speed a feature.
> Benefits: We will have files separated. It’s going to be better.
The plan is:
1. Split up the files.
2. Get rid of the as much of the dispatcher.js as we can and have web pack do the routing dynamically. That would eliminate most of 1 large confusing file (dispatcher.js). JS is still cached for the pages you visit but it isn't 1.5mb of JS it would be ~20kb of JS.
Kamil, GitLab CI/CD Lead
Docker socket timeouts have been floating around for a long time with no resolution: https://gitlab.com/gitlab-org/gitlab-runner/issues/2408
Intermittent HTTP auth errors causing build failures: https://gitlab.com/gitlab-org/gitlab-ce/issues/30670
More generally, tuning the runner's polling interval to minimize latency is also tricky, especially with multiple independent runners, and the runner doesn't handle 429s well in my experience (getting stuck in a tight retry loop without backing off sensibly, thus continuing to exceed its request limit).
Thanks for taking the time to solicit feedback.
I run a very small installation with only a couple of projects and some hundred issues on a 4 GB machine. It eats up 2 GB (sigh!!!) - and often still feels extremely slow. I mean 2 Gigabytes!! What for? That's a multitude of all the data I have in the DB there. And then it's not even used for something useful like caching. Some pages take several seconds to load. As a developer that's totally unacceptable to me.
Is ruby really such a mess that it's impossible to run an app with reasonable memory consumption?
There are a bunch of these small project/git-hosts, and while they're easy to manage they're less featureful than the gitlab offering. Gitlab does have some great features, such as the whole integrated CI system, built upon runners & docker.
The downside is complexity, and resource-usage. I know gitlab is free, and I could install it, but the added resources and potential security issues make it a non-starter.
Yes.
Any non-trivial Ruby app will quickly eat up 500MB, and any non-trivial Rails app will soon balloon to 1GB, with things getting worse over time due to memory fragmentation†. Since there is no parallelism your only option is to either have more unicorn workers, for which prefork and COW are hardly working to save you from duplicating memory, especially over time, or have puma threads and use JRuby, which is a memory hog of its own and often slower than MRI.
There have been arguments made that developer time trumps CPU time [0] but there are some workloads and problem domains and uncontrollable events for which this works at the beginning yet later on you find having yourself painted into a corner as suddenly things are not sustainable because you just can't throw more hardware at the issue without going belly up[1]. Once the low hanging fruits have been reaped you're being challenged just to make your app behave within established parameters with diminishing returns, which I'm sure you'd rather spend on solving actual problems for your customers. At that point you might just as well spend the money on rewriting part or all of your app in a more frugal ecosystem and mindset[2].
† Switching to jemalloc may or may not help. Over here it did not.
[0]: https://m.signalvnoise.com/ruby-has-been-fast-enough-for-13-...
[1]: https://twitter.com/migueldeicaza/status/950054181045440518
Any cloud provider will provide a VM that can comfortably run it for a very reasonable price.
I'm using the gitlab-omnibus one.
Being a PHP developer myself it's really hard to believe that resource consumption is obviously treaded with so little priority in the rails/ruby world.
And some attitudes here like "who cares? memory/cpu is cheap nowadays" are in my opinion part of the problem. I'd say, well written software should use as little resources as possible. Probably a habit that comes from my early days on a C64 back in the 80s.
It's about priorities. IMO if using as little resources as possible is priority number 1, then something is amiss.
For example, the average response time of an issue page has come down from 2.5s to 750ms over the last 6 months.
We still have a lot to do, but we're getting there.
> Yeah, and they've promised to work on performance for ages now with almost
> no improvement.
A specific GitLab.com issue in December 2015 vs January 2018 (I can't seem to find what the exact URL is):
2015: http://stats.gitlab.com/1902794/2015/12
2018: http://stats.gitlab.com/1902794/2018/01
Apart from that you can take a look at any of the past release posts or merge requests tagged with "performance" [1][2] and you'll see that plenty of improvements have been made over time.
> Is ruby really such a mess that it's impossible to run an app with
> reasonable memory consumption?
[1]: CE improvements: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope...
[2]: EE improvements (some of these may be merges from CE): https://gitlab.com/gitlab-org/gitlab-ee/merge_requests?scope...
Unfortunately this is almost never the case: Sometimes the pages load even slower. In the best case there's not much difference. Same goes for memory consumption.
But I understand now that this will always be a problem with rails.
We've also got an entire team dedicated to porting our Git layer to Go with Gitaly[1], which has been a major bottleneck that we've started resolving over the last year or so.
[0]: https://gitlab.com/groups/gitlab-org/-/merge_requests?label_... [1]: https://gitlab.com/gitlab-org/gitaly
Fortunately, gogs is a thing.
EDIT:
I would like to add that if this feature is in fact really useful and it works, the price for the GitLab Ultimate is justified if the license does not restrict you to the number of targets you can test. It can be used as a service and could potentially replace other infrastructure in a typical corp environment that is used mainly by the security team. But as I said earlier, this is a non-trivial task.
EDIT 2:
This is my last edit. We use GitLab CI internally and it is quite nice although it is not without issues. There are some really funky problems. But it works and I love the fact that it is integrated into the GitLab product. Except for TravisCI which makes it trivial, most other CI tools are very difficult to setup and maintain and for small teams this is yet another annoying thing to do. As a startup, I can say it is very useful.
That said, this integration isn't really adding much over just defining a build step that runs the check (unless you're using AutoDevops to have this run on all your repos). You could just provide a Gitlab/other CI config snippet for users to run the tool.
If your product is as cool as you say it is we would love to add it to GitLab by default and run both ZAProxy and yours by default.
What are the funky problems you encountered?
Btw, when I say funky, I don't mean bad. I mean mild annoyance.
Kamil, GitLab CI/CD Lead
We're not using that method of either hosting GitLab or deploying our software at my company for various historical reasons, and while GitLab has been good for us overall in its basic workflow, it's a bummer how much of the future roadmap and CD/Devops improvement seems not to apply to our setup.
Take monitoring for example. You can add Prometheus monitoring to (nearly) anything. But if you happen to use it with Kubernetes, we'll grab a bunch of data automatically. If not, you may have to configure it yourself.
We don't use Gitlab for CI. We use Jenkins.
For task and issues management we use JIRA.
Yes, it's 3 tools to manage but since each of the tools is really optimized for its task, it works really well.
I sure miss CircleCI step folding in the log output though.
Though I appreciate to have a Github alternative with some really solid CI tools, it just feels like Gitlab cannot compete. Discussions and the UI in general are unreadable, everything feels slow (10 seconds to populate the asignee dropdown, come on...), updates and deployments every two days in the middle of work days ("sorry, I cannot push, Gitlab is down"), and the cringiest thing of all, seeing: "deploying Gitlab CE 10.4.0-rc8" [1]. Releasing Release Candidates?!
Maybe I should try to deploy Gitlab on some server of my own.
[1] https://twitter.com/gitlabstatus/status/954491741322776582
Give me solid black lines for orientation, dammit.
It's not just an issue with merge requests or issues, it's more of a general thing – the colour palette and typography do not make GitLab easy to scan in the same way that GitHub is. I find it requires much more mental overhead to parse GitLab.
@Sarrah: I put some of my thoughts here: https://news.ycombinator.com/item?id=16214892
Also possibly worth mentioning, I have the same problems with much of the marketing site and blog, not just the application.
Some decide to put in the extra work and rename that last working release candidate and remove the '-rcX' from the file names.
That is correct, we deploy our RCs to production. I consider RC as only a point in time snapshot of a release that will be sent to public.
One thing that is incorrect is that we push all our RCs to production. For example, this release RC1 did not get to GitLab.com because during deployment to our other environments we found an issue that could have caused a large problem at scale. However, we executed a lot of QA and FA tests against all our RCs. You can see this here https://gitlab.com/gitlab-org/release/tasks/issues?scope=all... .
If we only deployed a final release, we would most likely be overwhelmed with the amount of changes GitLab receives and it would be hard for us to monitor and limit the impact.
We are working on getting to continuous deployment to GitLab.com, and as part of this push we started right now with the tools we have at our disposal. One of the ideas to get to stable, non impactful deploys was to create many RCs. Thinking was that if we have a smaller delta between the RCs, we can more effectively check the changes and reduce the overall impact. We also wanted to make sure that we over-communicate our status updates so that we can get feedback in case we overlooked something.
Was it problem free? Nope. Did it limit the impact to users? I firmly believe so. We have a lot of work to do to get to blue-green deployments and continuous deployment on GitLab.com scale while we also continue to ship to on premise customers. I do believe that we will get there the best way we know how to, and that is iterating on changes.
I hadn't recorded them or looked it up, hence the use of the word "seem", but this is at least good to hear.
> Was it problem free? Nope. Did it limit the impact to users? I firmly believe so.
You may be right. It might have been worse, and perhaps releasing more frequent low-impact changes helped, but I'm somewhat unconvinced. Orchestration was known not to be stable; given that, I would typically try and minimise deployments until orchestration had been more comprehensively tested and/or staging/canary environments had better parity with prod.
Additionally, the deployments were done in the middle of work days (as has been mentioned elsewhere), at highly inconvenient times (just before Christmas!), with little to no warning to users, hinting that bad internal planning must have played some part. When queried, the reply was literally that there is no schedule[0] . This response does not instill confidence.
> I do believe that we will get there the best way we know how to, and that is iterating on changes.
I really hope this is true—I'm still using Gitlab myself—but while I was an advocate 6 months ago, I've very much put such advocacy on hold for the moment.
Also, just to mention, I really appreciate there are GL employees on HN commenting on these threads. I've received a reply before elsewhere (on perf. and Gitaly) and it's been enlightening and informative. I really do like the transparency in this organisation, and have done my best to be as patient as possible with the stability/perf. issues up until now. But it's really become a bit ridiculous at this stage.
[0] https://twitter.com/gitlabstatus/status/943574131425140736
It's always the middle of a work day in some part of the world. It's always going to be inconvenient for someone.
Do these updates really cause significant outages or just slower response times due to invalidated caches or whatever?
The dogfooding-preleases-on-Gitlab.com idea in general seems perfectly reasonable to me. They're the ones best equipped to deal with any resulting issues so catching them before the majority of on-premise users is going to hit them seems like a very good idea.
If they wouldn't do it, do you think the possible issues would magically disappear until GA? How?
I run one for a community of hobby developers and to keep my stuff out of github for ideological reasons, but it's running on what is, by _FAR_ the most beefy machine I run.
Normally I have machines that are a couple cores, couple gigs of ram, or single purpose machines with under 1G and a dedicated thread on the hypervisor.
Gitlab has a 32G DDR3/8 Physical core CPU machine to itself.
I consumes, at any given time, about 25% of that (before FS caches, which, you're going to want).
I had a friend running this before me on a VPS with 4G of memory and the thing was so annoyingly slow that we blamed the hoster and our users were turning back to bitbucket/github.
Since the upgrade, things are smooth as a babies butt.
Although it's hard to justify the SERIOUS expense of this server, it's certainly fast enough. I worry about larger deployments though.
Btw, you can get a taste for yourself if you like; https://git.drk.sc
Maybe it doesn't scale very well with many users/projects. We've only got a couple hundred projects and around 100 users. (and only a handful of CI runners)
blazingly fast (a single war file - just run "java -jar gitbucket.war" to get started) and has a very nice UI. A plugin system enables you to extend the functionality (including CI) ... and a very active dev community.
So to get a general idea of what sort of setup is expected in order to run a gitbucket instance, if you're running one, what are the relevant details?
Also, they have repo mirroring which as I understand is not available on gitlabs CE edition.
On top of that we had constant issues with pull requests causing internal server errors, the merge check failing in mysterious ways, and so on. These issues may have been fixed now. We ended up switching to GitLab, and while it's quite resource intensive, performance seemed much more consistent.
But I have to second the resource usage - GitLab runs on beefier machines than our production database cluster. We are throwing everything at it, and performance still sucks. Both in terms of UI responsiveness and CI builders which are around 2-3 as slow as a local docker build.
For example, we have not yet seen a good enough reason to migrate our production database to use NVMe disks. But for GitLab server and CI builders - very much so (for a modest boost in performance).
But then again, I still think I get my money's worth.
That's inaccessible over IPv6 along with what I presume to be the community's website (https://darkscience.net). As far as I can tell GitLab itself support IPv6 with ease, although gitlab.com doesn't (https://gitlab.com/gitlab-com/infrastructure/issues/645) due to limitations from Azure.
Thanks for letting me know.
The GitLab hosted service is not really a competitor of GitHub at all; in fact, their (primary) marketing is based on self-hosted service.
In my opinion, this has connection to the corporate/engineering culture - GL relies on young and very sharp... but also underpaid minds, at least when compared to GH.
I speculate that in order to have a high performing and stable infrastructure, you need grey beards, who require salaries that GL doesn't offer. I highlight speculation - but I'm not surprised when the company losing 6 hours of data is one rather than the other.
If this is correct/realistic, it's not a negative judgment; it's just a different orientation.
So it really depends how long in the past you are talking about :)
Also, I am wondering if you were looking at a much older version of GitLab with the discussion and the UI being unreadable. We've made a ton of improvements to our UI in the past year. If you are looking at a recent version, can you tell me what is unreadable about the discussions and the UI in general? That way we can fix it.
One thing I dislike very much about the UI in general is the fixed/sticky header, which wastes precious vertical space (especially with an Ultra Wide monitor since there's mostly nothing in it). Also due to its color I find it distracting when reading code, would love I could just scroll down to make it go away.
Most of the time I'm using the left sidebar, not the top one. For the few times I want to use the top bar, scrolling up really isn't an issue. Note that GitHub also doesn't have this.
For the assignee dropdowm, it was roughly 6-8 weeks ago. I just went back to an old project and things seem to be much faster now.
In the past 3 years, I had to work on Gitlab a few times (for a few months every time), and at the end of every project, I had this feeling of: it was slow (push speed at the time could take 5-10 seconds when it was almost instant on Github), and basically all request were slow (dynamic dropdowns, posting a comment...). It is good to see you are focused on fixing these problems though :)
For the UI thing, a few points:
- imho, there's just too much on screen. I would say Gitlab is to Github what IntelliJ is to Atom: too much features I don't want to use/see. They just distract me. - the container in the middle is too large, there too many word per line and things get hard to read - Even with the breadcrumb, it is really hard to see "where" I am in the app (which project) - In the issue details page, it is hard to see the continuity of the comments, what is a comment and what is an action ("assignee changed from to..."). I cannot quickly go through an issue an getting on overview of the discussion easily.
I think these are mostly tiny UI things to change, and only with some typeography improvements, some borders and better contrasts, things will be a lot more clear.
Of course, all of this is highly subjective.
5mn of CSS tweaks: https://imgur.com/a/FLTJT (ofc it adds other issues/concerns, but you get the idea, I am no designer, but sensible to nice UIs)
On the other hand
> Cloud Native GitLab Helm Chart. THIS REPOSITORY IS UNDER HEAVY DEVELOPMENT. IT SHOULD NOT BE USED FOR ANYTHING EXCEPT DEVELOPMENT
So, what should I use now? also,
> A migration will be required to move from the current deprecated chart, to the new cloud native GitLab chart.
Yet I don’t see any explanation for how to migrate?
https://docs.gitlab.com/ee/install/kubernetes/gitlab_omnibus...
It's in beta, with some limitations on it's production-worthiness - basically that the Postgres Helm chart that it depends on isn't configured as well as the Postgres built into regular Omnibus.
I know it's confusing that we've got several charts, but we're trying really hard to reduce that down to one as quickly as possible.
> This Helm chart is in beta, and will be deprecated by the cloud native GitLab chart.
I interpreted it as this being deprecated.
That said, great work on performance and startup times in the past months, for the first time my 2-user GitLab isn’t maxing a full core and using 6GB RAM anymore, but instead using 60% of a core and 6.3GB RAM, while site load times have gone down significantly, and startup now completes actually within of the first 5 minutes (before, Kubernetes’ readiness checker often killed GitLab before it managed to come up)
Sorry for the confusion, as noted we are trying to remedy this with a single chart as quickly as possible.
Currently we have two Helm charts that can deploy GitLab, "gitlab" and "gitlab-omnibus".
* The "gitlab" chart deploys only GitLab itself and is not recommended. This is the chart that has been announced as deprecated in the blog post.
* The "gitlab-omnibus" chart is what we recommend users to install today, and deploys everything you need for a working GitLab installation. (Postgres, Redis, an Ingress, etc.)
We still support and maintain the "gitlab-omnibus" chart, but it too will eventually be deprecated as well in favor of the upcoming cloud native charts.
The cloud native charts will have a significant number of advantages, including:
* Separation of components for improved horizontal scaling
* Improved resilience
* Faster startup time (current container runs `gitlab-ctl reconfigure` on every startup)
* No need for root access
Due to the significant architectural changes, migration will be via backup/restore.
Oh my god, how much I'd love that.
On the topic of cloud native charts, can I use the new cloud native gitlab chart (if I run an external prometheus, postgres and redis already separately) today? And how would I migrate?
And one thing I'd love to see is building docker containers without having to give the runner access to the host's docker. How do other CI solutions do that?
The cloud native chart is still under development and breaking changes will occur, so I would not recommend using it for anything outside of testing. For example our current sprint is focusing on storage persistence.
For migration, you would perform a backup of the current instance and restore the backup onto the new cloud native based deployment.
I also wish they improve a bit the UI/UX in general. I've used Github for almost a decade and GitLab feels a bit messy.
It's basically unusable in it's current state.
Here's the issue for the table size: https://gitlab.com/gitlab-org/gitlab-ce/issues/41594
Doesn't seem worth the price bump from EES to EEU for me (which is a 4x per-seat increase), but this is a good feature for those willing to pay for it (or who already have another reason to buy the Ultimate edition).
Looks like my next task is to reimplement the DAST feature, which relies on the owasp/zap2docker-stable container under the covers.
For example: I have a single build box with a VM for linux, a VM for Windows, and one for OSX. When I commit, CI queues up the runners. Great. Except that there is some hard coded value of 1 hour after which the remaining jobs in the queue will get dropped. That means if a single job takes over an hour the remaining jobs will automatically fail, even if you up the job timeout limit. No error messages at all. Just failed jobs with blank logs.
You have to go in to a ruby configuration file and up the timeout to something big enough to accommodate your total time executing all runners, which means you must know that value in advance. Each update of gitlab kills that conf file so you have to log in and change it back and the stop/start the Gitlab instance.
Edit: clarification
GitLab CI/CD Lead
I've been pleased the text-content persists.
I will chime in with my experience. As a small startup, we have been using gitlab.com with a private CI server for over a year now. The UI performance has _most definitely_ improved. And their deployments do not cause outages anymore.
Great work team !
The only thing that would be neater would be if they offered an OS X and/or Windows runner in their CI. But since I'm not paying for the service, I'm pretty happy with how it works.
I saw that issue before but it refers to "gold subscribers" which I'm not (just another freeloader).
Definitely keep up the good work, it's an awesome product and it's awesome that you offer an open source release.
> GitLab has 2/3 market share in the self-hosted Git market [1]
Their CEO admitted that it was wrong here many times but chooses to keep those blog post up without correction. [2]
1. https://about.gitlab.com/2017/06/29/whats-next-for-gitlab-ci...
I would think the opposite. Generic claim of all "self-hosted" is a wider assertion than specific subset of enterprise.
Also blatant false claim of no 1 CI server is also there in the blogpost.
See responses to your similar comment here https://news.ycombinator.com/item?id=15704055
Also discounting jenkins as "not modern"( whatever that means) and declaring yourself as number one is so dishonest. You "standing by it" means nothing.
Why is so important to you push these lies, I don't get it.
I think that since the blue ocean update to Jenkins they have added lot of the next generation features. I'll either specify the claim better or lange it later today.
Don't make claims based on unreliable data. I am not sure how else to express this.
see similar comments here https://news.ycombinator.com/item?id=15704407
As promised I changed the wording of our CI/CD claims https://gitlab.com/gitlab-com/www-gitlab-com/commit/64ce89fd...
> we consider the data reliable.
I give up!
If course Google Trends is not equal to installed base. But based on our experience I also don't think gitosis still has a massive installed base.
However, as a reseller and a member of the HN community, I can offer HN a discount on list price which comes out of my cut.
Self-hosted: Gitea/Gogs, Phabricator, Tuleap
(Disclosure: I'm the author.)