17 ms·

GitLab 10.4 released

198 points by okket 9y ago

KeitIG 9y ago
I had to use Gitlab several times in the past, mostly because the companies I was working for wanted free private repositories. 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 https://twitter.com/gitlabstatus/status/954491741322776582
- foepys 9y ago
  Yes, the UI for issues and merge requests is atrocious with its light grey lines on a white background. I cannot skim a issue because I have to really concentrate on where a comment ends a new comment begins. Everything else also seems to float around in empty space, e.g. the emoji reactions. Give me solid black lines for orientation, dammit.
  - danpalmer 9y ago
    I've been asking for this for well over a year. Nothing yet. I think they need a fairly fundamental shift in design thinking.
    - svesselov 9y ago
      Hey Dan, Sarrah from the UX team here. I'd love to hear more about your thoughts here. Is there an issue you've created that you can point me to? If not, that's ok. Maybe you can tell me two or three UX changes we could make that you feel would have the most impact on MR and Issues.
      - danpalmer 9y ago
        Hi Sarrah, I raised it with the UX team in a feedback email a while ago. 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.
        KeitIG 9y ago
        This, about the mental overhead. So much. @Sarrah: I put some of my thoughts here: https://news.ycombinator.com/item?id=16214892 https://news.ycombinator.com/item?id=16214892
        danpalmer 9y ago
        FWIW I agree with pretty much all of those points. Great to point out things like line length and container size. Also possibly worth mentioning, I have the same problems with much of the marketing site and blog, not just the application.
  - svesselov 9y ago
    Thanks for the feedback. I've created this issue for the UX team to discuss ways we can make this better. We agree, there are a lot of opportunities for improvement here. https://gitlab.com/gitlab-org/gitlab-ce/issues/42331 https://gitlab.com/gitlab-org/gitlab-ce/issues/42331
- purerandomness 9y ago
  I'll bite on the last part about the release candidates: Technically, in software, every stable release originally was the last release candidate in which no showstopper bugs were found. Some decide to put in the extra work and rename that last working release candidate and remove the '-rcX' from the file names.
  - lucideer 9y ago
    This may be, but Gitlab seem to push all of their RCs to prod.
    - marinj 9y ago
      I work for GitLab and I was responsible for introducing release changes for this cycle. 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&utf8=%E2%9C%93&state=closed&label_name[]=QA%20task 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.
- dijit 9y ago
  What people don't understand about gitlab is that it's a absolutely monumental resource consumer. 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 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)
  - zebra9978 9y ago
    Suggest gitbucket - https://gitbucket.github.io/ https://gitbucket.github.io/ 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. https://gitbucket.github.io/ https://gitbucket.github.io/
    - pjmlp 9y ago
      Many thanks for the link, as Java/.NET dev it is surely a very good option to know about.
    - carussell 9y ago
      For anyone running this, can you comment? For example, one recurring criticism, before GitLab and the community managed to stamp out the expectation that it would be feasible, was that people were trying to self host a GitLab instance on a cheap SBC (e.g., a Raspberry Pi) or the smallest DigitalOcean plan and were surprised when this wasn't doable, while Gogs and Gitea handle this fine. 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?
- pizza234 9y ago
  > it just feels like Gitlab cannot compete 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.
- wodenokoto 9y ago
  I use it at work and haven't had anything to complain about, but we are using the self-hosted version.
- zhan_eg 9y ago
  Using gitlab.com with a group of ~20 devs - one of the main complains some of them had was 'It is slow'. From the last few months I hear more and more 'It is not so slow now, same as github'. So good job on all the performance improvements, users can feel them. So it really depends how long in the past you are talking about :)
  - mydigitalself 9y ago
    Thanks, glad you've noticed the improvements. We've still got more to do, but it's been an important part of every release for a while now.
  - jdc0589 9y ago
    seconded. I don't know whats been worked on in the past year, but its gotten a lot snappier overall.
- jakecodes 9y ago
  Jacob from GitLab here. Would love to help you out with your assignee dropdown taking 10 seconds. Currently on GL.com I see it takes 102ms. https://imgur.com/a/vSV21 https://imgur.com/a/vSV21. 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.
  - jhasse 9y ago
    > the UI in general? 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.
  - KeitIG 9y ago
    Hello Jacob, glad to see Gitlab employees around! 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 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)
nilsjuenemann 9y ago
It looks like that GitLab got the Featuritis. Instead of adding tons of unready and half baked feature it should focus on stability and performance.
- romanovcode 9y ago
  They got this disease long time ago. Instead of focusing 110% on UI and performance they just push more features.
  - NicoJuicy 9y ago
    Things have changed and seem to be measured. Change too much and your existing customer base won't like it
- pzduniak 9y ago
  They're improving performance and UI though, the new features only go to EE* versions. The new features are only a reason for them to get new Enterprise subscribers.
- mikekchar 9y ago
  This may be completely unfair, but I think it's a drawback of the business model they have. When you have an "open core" that you don't charge for, you have to have something that you can charge for. If you make the "enterprise edition" performant with good UX and the "community edition" slow and clunky then you threaten to kill off your potential user base. On the other hand, if you spend all your time improving the core, then there is nothing for people to buy. The prudent thing to do is to do as little as possible on the "core" because it is essentially a marketing expense. You need to invest as much as possible in the extensions that bring in revenue. 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 ;-).
pritambarhate 9y ago
At my company, we use Gitlab only as version control system and it works very well for around 100 programmers. We run it on an EC2 medium instance, around 200 GB standard SSD storage. 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.
- Waterluvian 9y ago
  Didn't even know gitlab has CI. At my office we have Jenkins plugged into our local gitlab instance.
  - iriche 9y ago
    GitLab CI works really well, haven't looked back at Jenkins since I swapped
    - bobviolier 9y ago
      Same here! We love GitLab CI
    - raarts 9y ago
      Agreed. Love it.
  - lloeki 9y ago
    GitLab CI is, for us, configurable in ways that CircleCI and Travis are not, by a long shot (but they both have other features that gitlab doesn't have, it's just that we don't need them) I sure miss CircleCI step folding in the log output though.
    - allan_s 9y ago
      this, step folding is definitely missing in gitlab-ci compare to travis, especially as it seems most CI product have it and (I think) it something that only require frontend developement ?
jpkeisala 9y ago
Who are competitors of Gitlab?
- marcinkuzminski 9y ago
  I'd say Github, Atlassian (Bitbucket server), RhodeCode, Perforce (after acquisition of Deveo)
- MadcapJake 9y ago
  Hosted: GitHub, SourceForge, BitBucket Self-hosted: Gitea/Gogs, Phabricator, Tuleap
  - wodenokoto 9y ago
    Github Enterprise is on-premise, so I'd call it self hosted. https://enterprise.github.com/faq https://enterprise.github.com/faq
  - lucideer 9y ago
    Phabricator also has a hosted option in Phacility
- dankohn1 9y ago
  Please see the CI/CD box at the top right of the Cloud Native Landscape: https://github.com/cncf/landscape#current-version https://github.com/cncf/landscape#current-version (Disclosure: I'm the author.)
  - deleted 9y ago
    [deleted]
- ethomson 9y ago
  All the tools that have been mentioned already and Visual Studio Team Services, which offers agile project planning, unlimited private git repositories (free for up to 5 users) and hosted CI/CD pipelines. http://visualstudio.com/team-services http://visualstudio.com/team-services
_pdp_ 9y ago
The security testing feature is definitely interesting but I wonder how it performs as that by itself is a non-trivial task. It can be done for sure but it takes a lot of resources and care to make it useful. 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.
- theptip 9y ago
  The DAST feature uses ZAP under the covers, their integration is a thin trigger around that tool. You can already use it for free outside of GL. https://hub.docker.com/r/owasp/zap2docker-stable/ https://hub.docker.com/r/owasp/zap2docker-stable/ https://docs.gitlab.com/ee/ci/examples/dast.html https://docs.gitlab.com/ee/ci/examples/dast.html
  - _pdp_ 9y ago
    I was suspecting that. Thanks for sharing this info. It will be really nice if you guys implement ways to swap the built-in DAST tool. My startup is actually going to release something really cool and useful in the next couple of weeks and it will be awesome if we can provide features to be compatible with GitLab.
    - theptip 9y ago
      I think you just need to drop a JSON file with the right format into the `artifacts` directory. 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.
kuschku 9y ago
> The gitlab Helm chart is deprecated, and will be replaced by the new cloud native GitLab chart. 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?
- Snappy 9y ago
  From https://docs.gitlab.com/ee/install/kubernetes/ https://docs.gitlab.com/ee/install/kubernetes/, the best way to run GitLab on Kubernetes today is the gitlab-omnibus chart: https://docs.gitlab.com/ee/install/kubernetes/gitlab_omnibus.html 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.
  - kuschku 9y ago
    That’s the one I’m using, but based on today’s release page saying the Helm chart is deprecated and I should use the cloud-native GitLab chart, and based on what your link to the Omnibus chart says: > 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)
    - joshlambert 9y ago
      Hi Kuschku, 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.
dominotw 9y ago
reminder: gitlab still has blatant false claims on their website. > 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/ https://about.gitlab.com/2017/06/29/whats-next-for-gitlab-ci... 2. https://news.ycombinator.com/item?id=15703221 https://news.ycombinator.com/item?id=15703221
- urbanjunkie 9y ago
  You should probably learn to read properly.
- als0 9y ago
  Your second link says something different. He refuted the phrase "Gitlab is a software product used by 2/3 of all enterprises", which would have been a far bigger claim than "self-hosted Git market".
  - dominotw 9y ago
    > "Gitlab is a software product used by 2/3 of all enterprises", which would have been a far bigger claim than "self-hosted Git market". 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.
- sytse 9y ago
  I stand by the claim we have 2/3 market share in the self-hosted git market. The claim is now linked to a page that contains the details https://about.gitlab.com/is-it-any-good/ https://about.gitlab.com/is-it-any-good/
  - dominotw 9y ago
    buddybuild and bitrise are not representative of * all * self-hosted git market. Your claim is totally absurd. See responses to your similar comment here https://news.ycombinator.com/item?id=15704055 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.
wyldfire 9y ago
I've started using gitlab for an open source project and I really like it. With respect to git repos it's indistinguishable from GitHub (or better?), plus it has CI features integrated in. 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.
- connorshea 9y ago
  We do have support for macOS and Windows in Runner, though you'll have to run them yourselves. We're looking into offering hosted macOS and Windows Runners for the future, but we have no solid timeframe for those right now. https://gitlab.com/gitlab-com/infrastructure/issues/3183 https://gitlab.com/gitlab-com/infrastructure/issues/3183
  - wyldfire 9y ago
    Yeah, sorry if I was unclear -- it's supported by the product but no runners are available for the gratis service. 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.
protomikron 9y ago
CI is fine and I am happy GitLab is offering it as it makes sense to integrate strongly with source control. But building a web-IDE? 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).
- Snappy 9y ago
  We're not trying to replace your local editor. We know you love them. But there are still lots of reasons and situations where a web IDE is perfect and beneficial.
  - ianwalter 9y ago
    Please do replace my local editor.
- zellyn 9y ago
  I was at Google when they implemented something like this in their source code viewing system. If you see a typo in a comment, for example, you click the pencil icon on that line, which pops open an editor with your cursor on that line, fix the typo, and can create and submit for review a pull request right there. Less than a minute. It is fantastic. I'm so glad Gitlab is providing competition to Stash and Github. Nice work.
  - segmondy 9y ago
    Someone in my twitter feed was just asking for this feature last night. I don't want to open an editor, checkout, fetch, edit, commit, push, open a PR to a PR when I can just do it in an editor. I don't use Gitlab but I agree, it's a brilliant feature.
    - sytse 9y ago
      Thanks! There is a place for web editors (quick edits, new projects) and local editors (working on the same codebase for a longer time). 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/ 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.
atsaloli 9y ago
Just a reminder, as a GitLab reseller, I offer a 10% discount on GitLab Enterprise Edition to the HN community. My email is in my profile.
- aaron-lebo 9y ago
  Could you explain the reseller thing? The Gitlab people are on HN, why don't they just sell directly to the community?
  - atsaloli 9y ago
    Oh, they do. You can buy directly from GitLab at https://about.gitlab.com/products/ https://about.gitlab.com/products/ 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.
    - aaron-lebo 9y ago
      Thanks. Good luck.
Gee19 9y ago
Has the CI/CD > Environments table styling been fixed? All the environment names are cut off and the table isn't resizable/sortable/searchable. It's basically unusable in it's current state.
- connorshea 9y ago
  Thanks for the feedback, I looked into it and it looks like neither of these problems have been fixed as of yet. I've asked the CI and UX teams if we can work on the Environments page. Here's the issue for the table size: https://gitlab.com/gitlab-org/gitlab-ce/issues/41594 https://gitlab.com/gitlab-org/gitlab-ce/issues/41594
ggregoire 9y ago
I still have 20 FPS when scrolling in a big commit diff. 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.
- darek 9y ago
  After a few years on GitLab I moved to GitHub for these very reasons. GitLab's UI was messy and it was slow to display (as in input lag and low FPS on my reasonably powered desktop PC).
- jakecodes 9y ago
  Hi Jacob, Frontend Lead here. This is very high on my list. I have a team of 5 FE engineers (1 being me) focused on improving performance and this is one of the big things on our list of highest priority performance improvements.
theptip 9y ago
The static/dynamic scanners are pretty cool; I just spent a couple days configuring the same functionality using the underlying open-source projects Clair (for Docker) and Bandit (for Python). 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.
relaxatorium 9y ago
Are most if not all of GitLab's future CI and CD improvements going to be focused on using Kubernetes and/or containers exclusively? 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.
- Snappy 9y ago
  We're definitely doing a lot with Kubernetes, especially within CD, but it's not completely exclusive. We usually provide powerful primitives that can be used for anything, but make it easier if you're using Kubernetes. 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.
jancsika 9y ago
I like Gitlab a lot, but I still struggle with things that shouldn't be hard. 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
- ayufan 9y ago
  Thanks. We are aware of this issue, and we even know what is causing that, we also have ideas how to fix that. The plan is to release a fix with 10.5: https://gitlab.com/gitlab-org/gitlab-ce/issues/38265#note_55320316 https://gitlab.com/gitlab-org/gitlab-ce/issues/38265#note_55.... GitLab CI/CD Lead
  - jancsika 9y ago
    What's frustrating is that is a regression-- I used to be able to queue up many jobs and never got the job failures (which, again, give no error message whatsoever).
- pault 9y ago
  I started using gitlab yesterday and during one merge request cycle I managed to lose my textfield contents several times. Keeping form contents backed up to session storage is a trivial task and it's maddening that they haven't implemented it in an area where you might be spending 20 minutes writing a comment then lose it when you change some value in a select menu. Really bad UX. Changing a merge target shouldn't require a full page refresh.
  - Snappy 9y ago
deedubaya 9y ago
I tried to sign up to GitLab the other day. OAuth for Google seems to be broken for me. I reached out on twitter, and it never got resolved. Just me shouting into the void, apparently. ¯\_(ツ)_/¯
- connorshea 9y ago
  Hey, sorry about that. I just replied.
agnivade 9y ago
Looks like HN loves to shit on Gitlab. 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 !

198 points by okket 9y ago

I had to use Gitlab several times in the past, mostly because the companies I was working for wanted free private repositories. 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 https://twitter.com/gitlabstatus/status/954491741322776582

foepys 9y ago
Yes, the UI for issues and merge requests is atrocious with its light grey lines on a white background. I cannot skim a issue because I have to really concentrate on where a comment ends a new comment begins. Everything else also seems to float around in empty space, e.g. the emoji reactions. Give me solid black lines for orientation, dammit.
- danpalmer 9y ago
  I've been asking for this for well over a year. Nothing yet. I think they need a fairly fundamental shift in design thinking.
  - svesselov 9y ago
    Hey Dan, Sarrah from the UX team here. I'd love to hear more about your thoughts here. Is there an issue you've created that you can point me to? If not, that's ok. Maybe you can tell me two or three UX changes we could make that you feel would have the most impact on MR and Issues.
    - danpalmer 9y ago
      Hi Sarrah, I raised it with the UX team in a feedback email a while ago. 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.
      - KeitIG 9y ago
        This, about the mental overhead. So much. @Sarrah: I put some of my thoughts here: https://news.ycombinator.com/item?id=16214892 https://news.ycombinator.com/item?id=16214892
        danpalmer 9y ago
        FWIW I agree with pretty much all of those points. Great to point out things like line length and container size. Also possibly worth mentioning, I have the same problems with much of the marketing site and blog, not just the application.
- svesselov 9y ago
  Thanks for the feedback. I've created this issue for the UX team to discuss ways we can make this better. We agree, there are a lot of opportunities for improvement here. https://gitlab.com/gitlab-org/gitlab-ce/issues/42331 https://gitlab.com/gitlab-org/gitlab-ce/issues/42331
purerandomness 9y ago
I'll bite on the last part about the release candidates: Technically, in software, every stable release originally was the last release candidate in which no showstopper bugs were found. Some decide to put in the extra work and rename that last working release candidate and remove the '-rcX' from the file names.
- lucideer 9y ago
  This may be, but Gitlab seem to push all of their RCs to prod.
  - marinj 9y ago
    I work for GitLab and I was responsible for introducing release changes for this cycle. 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&utf8=%E2%9C%93&state=closed&label_name[]=QA%20task 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.
dijit 9y ago
What people don't understand about gitlab is that it's a absolutely monumental resource consumer. 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 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)
- zebra9978 9y ago
  Suggest gitbucket - https://gitbucket.github.io/ https://gitbucket.github.io/ 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. https://gitbucket.github.io/ https://gitbucket.github.io/
  - pjmlp 9y ago
    Many thanks for the link, as Java/.NET dev it is surely a very good option to know about.
  - carussell 9y ago
    For anyone running this, can you comment? For example, one recurring criticism, before GitLab and the community managed to stamp out the expectation that it would be feasible, was that people were trying to self host a GitLab instance on a cheap SBC (e.g., a Raspberry Pi) or the smallest DigitalOcean plan and were surprised when this wasn't doable, while Gogs and Gitea handle this fine. 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?
pizza234 9y ago
> it just feels like Gitlab cannot compete 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.
wodenokoto 9y ago
I use it at work and haven't had anything to complain about, but we are using the self-hosted version.
zhan_eg 9y ago
Using gitlab.com with a group of ~20 devs - one of the main complains some of them had was 'It is slow'. From the last few months I hear more and more 'It is not so slow now, same as github'. So good job on all the performance improvements, users can feel them. So it really depends how long in the past you are talking about :)
- mydigitalself 9y ago
  Thanks, glad you've noticed the improvements. We've still got more to do, but it's been an important part of every release for a while now.
- jdc0589 9y ago
  seconded. I don't know whats been worked on in the past year, but its gotten a lot snappier overall.
jakecodes 9y ago
Jacob from GitLab here. Would love to help you out with your assignee dropdown taking 10 seconds. Currently on GL.com I see it takes 102ms. https://imgur.com/a/vSV21 https://imgur.com/a/vSV21. 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.
- jhasse 9y ago
  > the UI in general? 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.
- KeitIG 9y ago
  Hello Jacob, glad to see Gitlab employees around! 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 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)

nilsjuenemann 9y ago

It looks like that GitLab got the Featuritis. Instead of adding tons of unready and half baked feature it should focus on stability and performance.

romanovcode 9y ago
They got this disease long time ago. Instead of focusing 110% on UI and performance they just push more features.
- NicoJuicy 9y ago
  Things have changed and seem to be measured. Change too much and your existing customer base won't like it
pzduniak 9y ago
They're improving performance and UI though, the new features only go to EE* versions. The new features are only a reason for them to get new Enterprise subscribers.
mikekchar 9y ago
This may be completely unfair, but I think it's a drawback of the business model they have. When you have an "open core" that you don't charge for, you have to have something that you can charge for. If you make the "enterprise edition" performant with good UX and the "community edition" slow and clunky then you threaten to kill off your potential user base. On the other hand, if you spend all your time improving the core, then there is nothing for people to buy. The prudent thing to do is to do as little as possible on the "core" because it is essentially a marketing expense. You need to invest as much as possible in the extensions that bring in revenue. 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 ;-).

pritambarhate 9y ago

At my company, we use Gitlab only as version control system and it works very well for around 100 programmers. We run it on an EC2 medium instance, around 200 GB standard SSD storage. 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.

Waterluvian 9y ago
Didn't even know gitlab has CI. At my office we have Jenkins plugged into our local gitlab instance.
- iriche 9y ago
  GitLab CI works really well, haven't looked back at Jenkins since I swapped
  - bobviolier 9y ago
    Same here! We love GitLab CI
  - raarts 9y ago
    Agreed. Love it.
- lloeki 9y ago
  GitLab CI is, for us, configurable in ways that CircleCI and Travis are not, by a long shot (but they both have other features that gitlab doesn't have, it's just that we don't need them) I sure miss CircleCI step folding in the log output though.
  - allan_s 9y ago
    this, step folding is definitely missing in gitlab-ci compare to travis, especially as it seems most CI product have it and (I think) it something that only require frontend developement ?

jpkeisala 9y ago

Who are competitors of Gitlab?

marcinkuzminski 9y ago
I'd say Github, Atlassian (Bitbucket server), RhodeCode, Perforce (after acquisition of Deveo)
MadcapJake 9y ago
Hosted: GitHub, SourceForge, BitBucket Self-hosted: Gitea/Gogs, Phabricator, Tuleap
- wodenokoto 9y ago
  Github Enterprise is on-premise, so I'd call it self hosted. https://enterprise.github.com/faq https://enterprise.github.com/faq
- lucideer 9y ago
  Phabricator also has a hosted option in Phacility
dankohn1 9y ago
Please see the CI/CD box at the top right of the Cloud Native Landscape: https://github.com/cncf/landscape#current-version https://github.com/cncf/landscape#current-version (Disclosure: I'm the author.)
- deleted 9y ago
  [deleted]
ethomson 9y ago
All the tools that have been mentioned already and Visual Studio Team Services, which offers agile project planning, unlimited private git repositories (free for up to 5 users) and hosted CI/CD pipelines. http://visualstudio.com/team-services http://visualstudio.com/team-services

_pdp_ 9y ago

The security testing feature is definitely interesting but I wonder how it performs as that by itself is a non-trivial task. It can be done for sure but it takes a lot of resources and care to make it useful. 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.

theptip 9y ago
The DAST feature uses ZAP under the covers, their integration is a thin trigger around that tool. You can already use it for free outside of GL. https://hub.docker.com/r/owasp/zap2docker-stable/ https://hub.docker.com/r/owasp/zap2docker-stable/ https://docs.gitlab.com/ee/ci/examples/dast.html https://docs.gitlab.com/ee/ci/examples/dast.html
- _pdp_ 9y ago
  I was suspecting that. Thanks for sharing this info. It will be really nice if you guys implement ways to swap the built-in DAST tool. My startup is actually going to release something really cool and useful in the next couple of weeks and it will be awesome if we can provide features to be compatible with GitLab.
  - theptip 9y ago
    I think you just need to drop a JSON file with the right format into the `artifacts` directory. 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.

kuschku 9y ago

> The gitlab Helm chart is deprecated, and will be replaced by the new cloud native GitLab chart. 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?

Snappy 9y ago
From https://docs.gitlab.com/ee/install/kubernetes/ https://docs.gitlab.com/ee/install/kubernetes/, the best way to run GitLab on Kubernetes today is the gitlab-omnibus chart: https://docs.gitlab.com/ee/install/kubernetes/gitlab_omnibus.html 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.
- kuschku 9y ago
  That’s the one I’m using, but based on today’s release page saying the Helm chart is deprecated and I should use the cloud-native GitLab chart, and based on what your link to the Omnibus chart says: > 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)
  - joshlambert 9y ago
    Hi Kuschku, 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.

dominotw 9y ago

reminder: gitlab still has blatant false claims on their website. > 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/ https://about.gitlab.com/2017/06/29/whats-next-for-gitlab-ci... 2. https://news.ycombinator.com/item?id=15703221 https://news.ycombinator.com/item?id=15703221

urbanjunkie 9y ago
You should probably learn to read properly.
als0 9y ago
Your second link says something different. He refuted the phrase "Gitlab is a software product used by 2/3 of all enterprises", which would have been a far bigger claim than "self-hosted Git market".
- dominotw 9y ago
  > "Gitlab is a software product used by 2/3 of all enterprises", which would have been a far bigger claim than "self-hosted Git market". 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.
sytse 9y ago
I stand by the claim we have 2/3 market share in the self-hosted git market. The claim is now linked to a page that contains the details https://about.gitlab.com/is-it-any-good/ https://about.gitlab.com/is-it-any-good/
- dominotw 9y ago
  buddybuild and bitrise are not representative of * all * self-hosted git market. Your claim is totally absurd. See responses to your similar comment here https://news.ycombinator.com/item?id=15704055 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.

wyldfire 9y ago

I've started using gitlab for an open source project and I really like it. With respect to git repos it's indistinguishable from GitHub (or better?), plus it has CI features integrated in. 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.

connorshea 9y ago
We do have support for macOS and Windows in Runner, though you'll have to run them yourselves. We're looking into offering hosted macOS and Windows Runners for the future, but we have no solid timeframe for those right now. https://gitlab.com/gitlab-com/infrastructure/issues/3183 https://gitlab.com/gitlab-com/infrastructure/issues/3183
- wyldfire 9y ago
  Yeah, sorry if I was unclear -- it's supported by the product but no runners are available for the gratis service. 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.

protomikron 9y ago

CI is fine and I am happy GitLab is offering it as it makes sense to integrate strongly with source control. But building a web-IDE? 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).

Snappy 9y ago
We're not trying to replace your local editor. We know you love them. But there are still lots of reasons and situations where a web IDE is perfect and beneficial.
- ianwalter 9y ago
  Please do replace my local editor.
zellyn 9y ago
I was at Google when they implemented something like this in their source code viewing system. If you see a typo in a comment, for example, you click the pencil icon on that line, which pops open an editor with your cursor on that line, fix the typo, and can create and submit for review a pull request right there. Less than a minute. It is fantastic. I'm so glad Gitlab is providing competition to Stash and Github. Nice work.
- segmondy 9y ago
  Someone in my twitter feed was just asking for this feature last night. I don't want to open an editor, checkout, fetch, edit, commit, push, open a PR to a PR when I can just do it in an editor. I don't use Gitlab but I agree, it's a brilliant feature.
  - sytse 9y ago
    Thanks! There is a place for web editors (quick edits, new projects) and local editors (working on the same codebase for a longer time). 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/ 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.

atsaloli 9y ago

Just a reminder, as a GitLab reseller, I offer a 10% discount on GitLab Enterprise Edition to the HN community. My email is in my profile.

aaron-lebo 9y ago
Could you explain the reseller thing? The Gitlab people are on HN, why don't they just sell directly to the community?
- atsaloli 9y ago
  Oh, they do. You can buy directly from GitLab at https://about.gitlab.com/products/ https://about.gitlab.com/products/ 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.
  - aaron-lebo 9y ago
    Thanks. Good luck.

Gee19 9y ago

Has the CI/CD > Environments table styling been fixed? All the environment names are cut off and the table isn't resizable/sortable/searchable. It's basically unusable in it's current state.

connorshea 9y ago
Thanks for the feedback, I looked into it and it looks like neither of these problems have been fixed as of yet. I've asked the CI and UX teams if we can work on the Environments page. Here's the issue for the table size: https://gitlab.com/gitlab-org/gitlab-ce/issues/41594 https://gitlab.com/gitlab-org/gitlab-ce/issues/41594

ggregoire 9y ago

I still have 20 FPS when scrolling in a big commit diff. 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.

darek 9y ago
After a few years on GitLab I moved to GitHub for these very reasons. GitLab's UI was messy and it was slow to display (as in input lag and low FPS on my reasonably powered desktop PC).
jakecodes 9y ago
Hi Jacob, Frontend Lead here. This is very high on my list. I have a team of 5 FE engineers (1 being me) focused on improving performance and this is one of the big things on our list of highest priority performance improvements.

theptip 9y ago

The static/dynamic scanners are pretty cool; I just spent a couple days configuring the same functionality using the underlying open-source projects Clair (for Docker) and Bandit (for Python). 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.

relaxatorium 9y ago

Are most if not all of GitLab's future CI and CD improvements going to be focused on using Kubernetes and/or containers exclusively? 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.

Snappy 9y ago
We're definitely doing a lot with Kubernetes, especially within CD, but it's not completely exclusive. We usually provide powerful primitives that can be used for anything, but make it easier if you're using Kubernetes. 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.

jancsika 9y ago

I like Gitlab a lot, but I still struggle with things that shouldn't be hard. 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

ayufan 9y ago
Thanks. We are aware of this issue, and we even know what is causing that, we also have ideas how to fix that. The plan is to release a fix with 10.5: https://gitlab.com/gitlab-org/gitlab-ce/issues/38265#note_55320316 https://gitlab.com/gitlab-org/gitlab-ce/issues/38265#note_55.... GitLab CI/CD Lead
- jancsika 9y ago
  What's frustrating is that is a regression-- I used to be able to queue up many jobs and never got the job failures (which, again, give no error message whatsoever).
pault 9y ago
I started using gitlab yesterday and during one merge request cycle I managed to lose my textfield contents several times. Keeping form contents backed up to session storage is a trivial task and it's maddening that they haven't implemented it in an area where you might be spending 20 minutes writing a comment then lose it when you change some value in a select menu. Really bad UX. Changing a merge target shouldn't require a full page refresh.
- Snappy 9y ago

deedubaya 9y ago

I tried to sign up to GitLab the other day. OAuth for Google seems to be broken for me. I reached out on twitter, and it never got resolved. Just me shouting into the void, apparently. ¯\_(ツ)_/¯

connorshea 9y ago
Hey, sorry about that. I just replied.

agnivade 9y ago

Looks like HN loves to shit on Gitlab. 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 !