Gitlab 11.8 Released | Hacker News Reader

Gitlab 11.8 Released

about.gitlab.com

175 pointsbjoko56 comments

You know, there was a thread the other day about a new release announcement for some IDE. It was quickly removed, on grounds that the Hacker News FAQ says you shouldn't repost something "If a story has had significant attention in the last year or so".

I remember thinking that it was a real stretch to interpret different release announcements, separated by months, as "duplicate" posts. But this was coming from dang himself, so I guess that's the authoritative view.

Just pointing out that Gitlab operates on a more or less monthly release cadence. Pretty much every release gets an announcement thread on HN's front-page for the full day. And usually there's a separate front-page thread or two in between, to announce stuff in upcoming releases. I've never once seen any of this removed, or even questioned.

I’ve submitted it a few times, just because I use it and like it, interested in discussion about it. I don’t know if I agree with the rule (a whole year?), but I’ll stop submitting it.

Oh, to be clear... I'm perfectly HAPPY with release announcements, and believe that strict interpretation was ridiculous.

I was simply taking issue with the inconsistency, arbitrary interpretation, selective enforcement, etc.

Same here.

I'm generally extremely impressed with HN mods but this is one of two (three) minor nits I see.

And to be clear I'd also prefer both to be accepted, at least a little softer duplicate check than today.

If the release isn’t noteworthy enough, wouldn’t the downvoted, or the lack of upvotes kill it anyways? I feel marking it as a dupe seems an unnecessary mitigation when these are the exact kind of things crowdvoting is really good at.

My take as well

(Note: obviously my opinion, not the actual rules)

I do think the rule should be based on the content of the release rather than the timing. If the software contains major new features every month that could be relevant to the HN audience I see no reason to remove the post, it's _new_ information being posted on Hacker _News_. (I haven't seen the referenced IDE update post so I don't have an opinion on it either way.)

Yeah, I think GitLab in particular is a really interesting product that competes in a crucial space for devs. In addition, they've committed and stuck with monthly releases, with new features/improvements, so that's why it's posted so much. I love the monthly releases though.

I think there's some understood weighting function based around familiarity and widespread use in the community.

In the beginning, I suspect pimping GitLab on Hacker News was tolerated because Y Combinator is an investor, and the company is viewed as potentially one of their home runs, with gazillions in returns. Further, there are many GL employees on HN who will promptly upvote or comment on submissions.

These days, GL is so popular that the echos of the early days continue. Self-fulfilling prophecy, achieved.

It's funny, I read your post and thought you must be talking about Lazarus. I did some searching and (I think) found the thread in question (I actually didn't see the submission, but was thinking of the 17 day old one that was marked a dupe and later unduped - which killed the momentum it had):

https://news.ycombinator.com/item?id=19169397

I too would like to see some clarity on this rule. I was bummed the 17 day old one was marked a dupe. I personally love Lazarus discussions, it's so interesting to look back on Delphi and think about how little our tools have improved. I think they are so popular because a lot of developers share that sentiment.

Ya, but gitlab is a YC company. So they aren't held to the same standard.

Overview of the three main improvements in this release:

1. JavaScript coverage in SAST

GitLab Static Application Security Testing (SAST) scans source code and helps to detect potential security vulnerabilities early in the pipeline. In 11.8, we've added SAST support for JavaScript, building on top of our existing node.js support. Now any JavaScript file can be scanned, like static scripts and HTML. A vital practice in DevSecOps is to scan code changes with each commit, and with this change, we're covering one of the most popular web languages, helping you to find JavaScript risks as early as possible.

2. GitLab Pages for subgroups and templates

GitLab Pages got a whole lot better this release, with two key improvements. First, we have introduced GitLab Pages support for projects in subgroups, enabling these projects to easily publish content to the web. GitLab 11.8 also bundles our most popular templates for Pages, so users can get started with just a single click.

3. Error Tracking with Sentry

Application errors provide important insight into the health of your application, and can help detect problems without waiting for users to report them. GitLab 11.8 can now display the most recent errors directly within the project, making them easier and quicker to find and take action on.

Gitlab is great and I have used it for years but I recently switched to Gogs for self hosted repositories because it is much faster, easier to set up and walk in a park to maintain. It doesn't have all the features (bloat) that Gitlab has but it can probably satisfy >95% of git users.

Yes but Gogs is self-hosted whereas Gitlab offers hosting solutions.

You can host Gitlab.

GitLab has self hosted solutions

Here's a link to the self-hosted GitLab https://about.gitlab.com/pricing/#self-managed

I'm somewhat dumbfounded at the no-less-than-three sibling commenters here all chiming in with the same repeated misinterpretation of your post.

I suspect those downvoting you didn't take time to read your comment properly either.

I blame the misunderstandings on the non-standard syntax: > Yes but Gogs is self-hosted whereas Gitlab offers hosting solutions.

Replying that, to someone who literally said they switched from GitLab to Gogs for self-hosted repositories, also made me parse it as implying one word: > Yes, but Gogs is self-hosted, whereas GitLab offers [only] hosting solutions.

but the author probably meant something like: > Yes, but Gogs is [exclusively] self-hosted, whereas GitLab [also] offers hosting solutions [so switching is not always an option].

Spot on. I'm a non-native english speaker, so my syntax sometimes leaves to be desired. Sorry for the confusion.

Did you look at Gitea before you stood up Gogs? I'm looking at both and will choose one shortly, any insight is most appreciated.

Gitea has more options and features, but it is more bleeding edge. Unkwon (Gogs author) handles contributions to Gogs very carefully, taking painstakingly attention to the code being submitted. That has resulted on a very stable, and reliable software. You decide. :-)

To rephrase what you said, Gitea is more community driven. You'd have a better chance contributing and fixing issues that impact you with Gitea, compared to Gogs.

Personally I switched over to Gitea.

One of the more tangible differences between the two is that Gitea bundles all the web assets into the executable used to run the service, so you just have a single exe replace on upgrades. It's been a while since I've used Gogs, but looking at their latest info you still need to remove some folders and not others when updating Gogs, because some of them are template and static files used by the web server.

Hello! Since GitLab is a single application that covers the entire software development lifecycle, we're a bit "bigger" than Gogs, which only tackles SCM. We have a plan to make GitLab use less resources, including forming a team to specialize in this area, and we're really grateful for your feedback. :)

May I know what is the requirements for who would join that team?

Hi! We just opened up hiring for an Engineering Manager and Senior Product Manager - I'd love it if you applied and we became teammates! :)

Engineering Manager: https://boards.greenhouse.io/gitlab/jobs/4201458002

Senior Product Manager: https://boards.greenhouse.io/gitlab/jobs/4192657002

I'm still in my early years of professional, so guess I'll wait for more low level and engineering focused roles open. Thanks.

> We have a plan to make GitLab use less resources

I used to use gitlab at work daily and releases would mention how performance is being tackled consistently. However, I have not seen any large improvements at all, suggesting that there is an impenetrable wall made of the underlying technologies.

Gitlab is based primarily on Ruby-on-Rails, which doesn't particularly shine with neither memory usage nor performance. What sort of effort would even reduce the use of resources significantly, short of a rewrite?

This "rails/ruby is slow" myth really needs to die. Sure, rails is too slow for certain very large companies at very large scales, and if you're in this position you already know it. However, rails is fast enough for 99.5% of usecases, gitlab included.

As to memory usage, I will concede it is often somewhat high with rails, but there are solutions, such as jemalloc that have helped me in the past.

Gitlab most certainly not included! Its perf is awful in comparison to any modern stack (including some php ones unfortunately).

I didn't say GitLab was fast (I haven't used it enough to know), but blaming its problems on ruby/rails when GitHub (which is pretty fast imo) is also written on rails is misleading at best.

Ruby/rails is not the only factor, but it is certainly one of the contributing factors, and it is a big one. There's no need to deny that.

A big thing we're looking at to reduce memory is making the ruby code multi-threaded. https://gitlab.com/gitlab-org/gitlab-ce/issues/3592

Where is the bottleneck? I’m not massively familar with Ruby, but I’m assuming the underlying language isn’t the problem and it’s more to do with the general architecture?

We already have it working in development. We're cautious because last time we enabled it in production we got a lot of memory usage and runtime errors. I think the problems are that the native extensions from some dependencies are not multi-threading safe but I might be wrong.

I do think they have made improvments to performance. Project search and loading the issues page used to timeout all the time on Gitlab.com, especially for the gitlab repo itself. Now it works much better, loads and searches at an acceptable speed with no timeouts.

I will say I've never had a problem with performance on self hosted Gitlab because of the smaller scale.

There has been a steady march of performance issues that have been made over the last few months that may not have been mentioned in the release post:

* 11.8: https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=...

* 11.7: https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=...

* 11.6: https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=...

With regard to memory usage, we've made some progress there as well. For example:

1. We cut 80-100 MB/per Unicorn process by removing a dependency: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21008

2. A change in our merge request processing in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22725 lowered gigabytes of runtime memory from our worst and most commonly-used Sidekiq background job.

3. In the second-worst performing Sidekiq job, switching to a faster XML processor in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23136 also dropped large spikes of runtime memory.

That being said, we still have a long way to go. I recently did an analysis to figure out, "Why does each Unicorn process take 400-500 MB RAM?" The note in https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4118#not... explains why. In short, there is truth that we're paying a price for Ruby overhead.

What can we do about it? I have several ideas:

1. Upgrade to Ruby 2.6 (significant memory improvements for free; see https://youtu.be/ZfgxvNUfQdU)

2. Replace many Unicorn processes with a multi-threaded Puma server

3. Continue profiling and optimizing inefficient code paths

4. Make the Ruby interpreter more efficient (e.g. with a compacting garbage collector, see https://gitlab.com/gitlab-org/gitlab-ce/issues/54555)

5. Make Rails more efficient (e.g. https://github.com/rails/rails/pull/34711).

Lastly, there may be significant parts of the code base that will need to be rewritten to improve memory and/or performance. Gitaly is a prime example of this: many Git-related calls have been abstracted into a Go process.

Thanks for putting that post together - that is very informative.

Hi Suri, since we're here and talking about this I too would like to let you know that I'm actively considering alternatives to gitlab for this reason.

I originally started using gitlab because it provided a VCS with a really nice built-in CI system. Really, I wanted github + travis-ci, but selfhosted.

My experience with gitlab has been and still is really great, but I'm losing my grasp on what's going on on my own server. Every time I install a patch, I discover my gitlab instance has grown kuberentes support or serverless features or whatever auto-devops is.

I don't want, use or need all that, I'm the only person who logs into my gitlab instance. I'm pretty sure I've got it all turned off, but only pretty sure. If gitlab grows any more features I'll be moving away simply to ensure confidence that I understand my own infrastructure in the limited time I have to maintain it.

It's the weirdest kind of success problem to have, but the truth is if it wasn't such a pain to make the move, I'd have transitioned away from gitlab 6 months ago.

Thank you so much for sharing your experience. I hadn't thought of how frustrating it could be to not recognize your instance after each patch installation. This line, in particular, made me pause while reading: `I'm losing my grasp on what's going on on my own server.`

I created an issue to document your feedback, and I'll follow up with the product team to share your concerns. I really, really appreciate your candor, and I hope your comment sparks serious conversation and helps guide the new Memory team.

Issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/58100

Thanks, I do appreciate it :)

I'll also completely understand if the decision is that I'm too much in the minority to support on this front. There are always trade-offs to be made as a product grows, the important thing is that those tradeoffs been actively considered rather than randomly selected. As long as you guys have thought about the cost of expanding features so fast and have decided how you want to handle the situation, I'll be happy.

I have been a GitLab CE user for several months now, hosted on my own server. And I agree the performance is not really good compared to GitHub. I know improvements like this is a huge challenge for you guys. But it’s been several years already since you guys said you are about to deal with performance issues.

Thank you very much for using GitLab. I wanted to share these details with you about the stability improvements https://about.gitlab.com/2018/10/11/gitlab-com-stability-pos....

I really like the update pace of Gitlab. Our teams are all based on an on-prem EE (low tier) and it's been a pleasure to receive a steady stream of valuable updates.

Passing on all the good things that Gitlab does for us already; I _really_ wish gitlab would push to make more of the Project Management features accessible to the lower tiers (maybe even CE). Epics and Roadmaps linked to Gitlab's SCM and DevOps features would be a _real_ contender to JIRA/Confluence in the market but it's currently hidden behind a very steep ~100$/m "ultimate" plan.

GitLab Community Advocate here. Thank you very much for the feedback. I understand your desire to move some features to the lower tiers and that's a good sign for us that we are on the right path with our offerings. From time to time it happens that we move some features to the lower tiers or even core/free tier.

I wanted to share few more words on how we are trying to be the good stewards, you can find more about our stewardship rules and promises here https://about.gitlab.com/company/stewardship/#what-features-...

Thanks for your comment. Glad to hear you like the update pace. Regarding epics we're considering moving them to a more affordable plan while keeping the roadmap in Ultimate. But we're not close to a decision.

Thanks for the update! I really think there's a huge opportunity of growth there that goes beyond SCM/DevOps for medium sized teams.

I like and use Gitlab, I just wish they would call it PR instead of merge request.

Funny thing, when I joined the team at GitLab over a year ago I was really annoyed by this since I'd been using PR for the better part of a decade. Now I'm so used to saying MR that PR sounds very strange. All in all, "merge request" is a more accurate term and no one ever gets confused about it like https://stackoverflow.com/questions/21657430/why-is-a-git-pu... I think it would be great if other tools just called it an MR as that seems to be the term that is easier to understand.

After joining you got brainwashed of course ;-)) It's a minor detail but it's still irritating for me that it doesn't have the same name as in Github. More accurate or not, but Github was first.

MR is much easier to explain to people who are not familiar with git than PR. Everyone who has used at least one version control system knows what merge is, whereas pull is a much less clear term.

Congrats on the new release!

Since GitLab for Education was announced I've been trying to get our college signed up for it, but it's been difficult so I was hoping I might be able to share some GitLab for Education Requests:

Working in a community college it's been really tricky to get the agreement signed for us to take advantage of this at all (that's more of an issue with the way we work in particular, but I just wanted to throw it out there that it would be nice if we could sign up for the licenses completely online without needing to wait and get an agreement signed because for example our president doesn't want to do an esignature so that means sending it over to their office for signature, waiting a long while, getting it back, and then finding out our deadline passed and haven't to try it all over again so if that process could be changed, or better yet removed, that would be great).

Related to the GitLab for Education license limitations...I originally though the Education licensing would cover usage for our IT Department staff as well, but it definitely seems to be limited to just Faculty/Staff type usage which ends up being a bummer for us since now I can't promote it anymore internally with us a free option we can sign up for anymore and other ideas I was potentially thinking of (the Group Issue Boards seemed like it could potentially be a nice way to organize Kanban Boards across the college and make it so that staff from other areas outside of IT could make use of Kanban Boards too...we've been using Kanboard inside of IT for a few years now, but haven't made a strong push to have other departments use it). In terms of affordability, that would limit us to licensing GitLab primarily for IT stuff only + for 10 users that's already going to be a pretty big cost for our small college / IT department.

Lastly, I know there's Wiki functionality and GitLab Pages already and that can be used for documentation to a degree, but is there any work towards building/including some sort of Confluence alternative into GitLab as well?

Right now we'd like start using some sort of nice, comprehensive documentation option, but I'm not really sold on Confluence at the moment. Admittedly, right now with the info about us needing to license GitLab for our IT department staff as well being fairly new to me that's thrown the whole idea of using GitLab out the window (almost), but the lack of a Confluence option built-in to GitLab would be another potential blocker for us (I do like the idea of having everything all under one system if possible to simplify usage for us).

tldr: If you can make edu licensing completely free (for staff too) and simple to use/signup for (without an agreement needing to be signed), plus add a Confluence alternative that would be awesome!

This comment is high quality customer feedback; it deserves a thoughtful consideration and response from Gitlab.

Thank you for the detailed feedback! We love to hear that we're doing something well, but also like to discuss if there is something that can be improved.

> It would be nice if we could sign up for the licenses completely online without needing to wait and get an agreement signed

That sounds reasonable, and it doesn't seem to be an issue only with your institution. We already have an issue for automating the application process for the educational license. [1] The proposed solution would resolve all concerns described here.

> I originally though the Education licensing would cover usage for our IT Department staff as well

The primary goal of this program is to help students catch up with the latest technology in software development as early as possible, and we think that we managed to do this with the current setup. However, we would love to discuss other options regarding this program's limitations. Please open an issue [2] - we would love to hear your suggestions.

> Is there any work towards building/including some sort of Confluence alternative

Can you please tell us more about what part of Confluence do you think is missing in GitLab? You can use this page as a reference - there are all stages of development that are covered by GitLab. [3]

Thank you again on your feedback, it is greatly appreciated.

[1] - https://gitlab.com/gitlab-com/marketing/community-relations/...

[2] - https://gitlab.com/gitlab-com/marketing/community-relations/...

[3] - https://about.gitlab.com/product/

Thanks for the reply, I'll look into putting in an official issue request for it in [2] you shared but just to add on a bit...on our end we're really not developer oriented at all (I've put up a VisualSVN server quite a few years back and then put up a Gogs server about 3 years ago) and I'm pretty much the only person that uses it.

Our CS offerings are pretty minimal so even though I would love to see usage expanded there as well (teaching/using Git for instruction) the reality is it would be lucky if 50 students made use of Git during a given schoolyear since the offerings are that limited right now (and we don't generally get a lot of signups for those classes). It'd be awesome to expand our program and also create some sort of tie-in with Silicon Valley companies somehow (we're a community college in Southern California in a rural community so job opportunities for tech locally are really slim...so unless we built some sort of partnership for remote opportunities where people could stay local and have a good remote job people basically have to leave to other communities in different parts of the state to get work).

So going back to the staff side...I'm just trying to get our own IT staff onboard with using Git and hopefully start integrating more DevOps type things into our workflow, but it's difficult when you don't have the right tools available (or there's a pretty big cost to them). For example, I love the idea of us starting to create private containers but we need a container registry to do that and that's something GitLab could help us out with. The other main thing is the issue boards which I think we'd be able to make good use out of as well, but can't really test out those ideas at the present moment easily.

For Confluence, I don't have a ton of experience with it...the main thing is that at least one of the other community colleges that's a bit of a tech leader in the state is using it for their documentation stuff and the state's CCC Tech Center is using it too so that makes folks think it's the best solution to try out. To be honest right now though we're not doing a great job on documentation currently, even though we have a lot of other "low-hanging fruit" type options to be able to try out and just document things currently if we really wanted to do so (so what I'm saying here is that I don't think getting/implementing Confluence would actually solve our documentation issues here...but it would be nice if GitLab had a piece that you could point at as equivalent to Confluence that way people could be more comfortable with using it as a whole solution, rather than looking at that one capability as "missing" and discarding the entire solution because of it).

A response shared by the other college using it mentioned the following use cases that they used Confluence for:

- Team Project Sites District-wide (new and ongoing software implementations) - “Bookshelf” Searchable district-wide software documentation library (Banner, Onbase, DegreeWorks, Argos, etc.) - Technology “Knowledge Base” – district-wide searchable problem/resolution, FAQ - District IT Policies and Documentation - Development Team Private Documentation (Banner, Onbase, DegreeWorks, Argos, etc.) - Operations IT Team Private Documentation - And more!

In terms of web application development, I'm the only staff member really doing that currently...pretty much all the rest of our "development" work consists of our analysts writing database queries, with the occasional database view/procedure being written, but that's the team that I'd like to have to start using version control a bit.

Our Ops side of the house still needs a lot of work to get into the "DevOps" mindset, and I've been limited in the stuff that I can try out and experiment with as well (e.g. I've wanted to experiment more with Docker, but since we're a Hyper-V shop primarily understanding Microsoft's support of Docker has taken some time...plus moving into production is another stage, etc. and I basically have to sort out those new approaches on my own).

Reply on news.ycombinator.com