Gitlab 11.8 Released

(about.gitlab.com)

175 points | by bjoko 1861 days ago

6 comments

  • StevePerkins 1861 days ago
    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.

    • rudedogg 1860 days ago
      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.

    • yutghgh 1861 days ago
      (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.)

      • markdog12 1860 days ago
        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.
    • markdog12 1861 days ago
      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.
      • StevePerkins 1861 days ago
        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.

        • addicted 1860 days ago
          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.
        • reitanqild 1860 days ago
          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.

    • michaelbuckbee 1860 days ago
      I think there's some understood weighting function based around familiarity and widespread use in the community.
      • 7e 1860 days ago
        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.

    • jjeaff 1860 days ago
      Ya, but gitlab is a YC company. So they aren't held to the same standard.
  • sytse 1860 days ago
    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.

  • Jnr 1861 days ago
    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.
    • Suri_GitLab 1861 days ago
      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. :)
      • chmln 1861 days ago
        > 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?

        • sytse 1861 days ago
          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
          • aidos 1860 days ago
            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?
            • sytse 1860 days ago
              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.
        • dashundchen 1860 days ago
          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.

        • stanhu 1860 days ago
          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.

          • chmln 1860 days ago
            Thanks for putting that post together - that is very informative.
        • yutghgh 1861 days ago
          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.

          • KaoruAoiShiho 1861 days ago
            Gitlab most certainly not included! Its perf is awful in comparison to any modern stack (including some php ones unfortunately).
            • yutghgh 1860 days ago
              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.
              • chinhodado 1860 days ago
                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.
      • Sir_Substance 1860 days ago
        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.

        • Suri_GitLab 1860 days 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

          • Sir_Substance 1859 days ago
            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.

      • dirtylowprofile 1860 days ago
        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.
      • letientai299 1861 days ago
        May I know what is the requirements for who would join that team?
    • W-Stool 1861 days ago
      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.
      • davidcollantes 1861 days ago
        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. :-)
        • tshannon 1861 days ago
          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.

    • StyloBill 1861 days ago
      Yes but Gogs is self-hosted whereas Gitlab offers hosting solutions.
      • lucideer 1860 days ago
        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.

        • manwithaplan 1860 days ago
          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].

          • StyloBill 1859 days ago
            Spot on. I'm a non-native english speaker, so my syntax sometimes leaves to be desired. Sorry for the confusion.
      • techntoke 1861 days ago
        GitLab has self hosted solutions
      • tenebrisalietum 1861 days ago
        You can host Gitlab.
      • dsumenkovic 1861 days ago
        Here's a link to the self-hosted GitLab https://about.gitlab.com/pricing/#self-managed
  • bbeausej 1861 days ago
    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.

    • dsumenkovic 1861 days ago
      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-...

    • sytse 1861 days ago
      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.
      • bbeausej 1860 days ago
        Thanks for the update! I really think there's a huge opportunity of growth there that goes beyond SCM/DevOps for medium sized teams.
  • laktak 1860 days ago
    I like and use Gitlab, I just wish they would call it PR instead of merge request.
    • williamchia 1860 days ago
      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.
      • chappi42 1860 days ago
        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.
        • chinhodado 1860 days ago
          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.
  • orware 1861 days ago
    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!

    • btasovac 1860 days ago
      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/

      • orware 1860 days ago
        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).

    • hitekker 1860 days ago
      This comment is high quality customer feedback; it deserves a thoughtful consideration and response from Gitlab.