17 ms·

Gitlab 9.0

deleted 10y ago
[deleted]
ploggingdev 10y ago
The performance improvements are very noticeable : general page load times, pushing code to gitlab is as fast as github now and the commit messages load insanely fast, compared to a few months ago where loading commit messages in the UI used to take at least a couple of seconds. I don't follow gitlab development too closely, but they seem to have focused a lot on improving cache performance. But one change that I did not like was the the removal of the side panel which could be pinned. Navigation required fewer steps, but now an extra click is required to bring up the options.
- victorwu 10y ago
  Thanks for the feedback regarding the sidebar navigation! Here's the issue that we used to chat extensively about it and came to our current design here in 9.0: https://gitlab.com/gitlab-org/gitlab-ce/issues/26200 https://gitlab.com/gitlab-org/gitlab-ce/issues/26200 There's lots of discussion there. We went with a design that leans on getting out of your way and recovers some screen real-estate. We do recognize the one additional click required though. And we are actively listening to feedback and will continue to iterate. We're working hard to improve usability and navigation in general. In addition to this sidebar change, we've made many nav updates: https://gitlab.com/gitlab-org/gitlab-ce/issues/26348 https://gitlab.com/gitlab-org/gitlab-ce/issues/26348.
  - tokenizerrr 10y ago
    Trading usability for screen real-estate? Sounds like your designers have gone off the deep end and fail to realize that Gitlab is a productivity tool, not an art piece.
    - connorshea 10y ago
      I'd argue that extra screen real estate for the content that matters often lends itself toward better UX, but any specific suggestions for improvements would be appreciated. :)
    - thoughtpalette 10y ago
      That's quite a bold statement from an armchair UX designer. They obviously have reasoning and supporting data, maybe you're in the minority of users who've found that useful?
    - victorwu 10y ago
      Thanks for the feedback! In this iteration, we think recovering more space helps users focus on content, and allows them to see more content at once. Definitely we recognize the tradeoff of additional clicks and discoverability as a result. We are definitely focused on usability, and navigation in general. We don't claim to know all the right answers all the time. So we are iterating with each release, and working hard doing user research as well to inform our decisions. You can see some of our recent work regarding nav here: https://gitlab.com/gitlab-org/ux-research/issues/3 https://gitlab.com/gitlab-org/ux-research/issues/3. Thanks.
  - tracker1 10y ago
    The application I'm working on, I went with a 3-state navigation... null (default), true (open) or false (closed) ... at large screen sizes null is a soft open, smaller soft closed... toggling goes between the respective hard state and the null/default state. At sm-medium, it's an overlay, at phone/xs it takes over the screen. I find that this is more intuative to use than a hard on/off only.
  - wjoe 10y ago
    I agree with the parent about the sidebar. I already disliked the change to make it hidden by default with the pin option since it was a bit inconsistent for me, but it at least gave the option for best of both worlds. Ideally this should be an option. I get that 'modern UX' is all about more screen space and whatnot, but I'm not a fan of that trend personally. It seems that all that's been gained from that change is more empty space at the side of pages. Personally, I'm the type that would rather have more information and convenience on the page than extra space. Would it be that hard to add an option to enable the side bar if people want it? That's what I like about GitLab, that it's very configurable.
- sytse 10y ago
  Great to hear you notice the performance improvements. We're very happy with the improvements but we still have long way to go. We want the 99% latency under 1s and right now it is 2s: https://drive.google.com/file/d/0BzQDcBnEfNRZSTZYVXlyc1FGdEk/view https://drive.google.com/file/d/0BzQDcBnEfNRZSTZYVXlyc1FGdEk... There are some controller timings that are red https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZZVZiRXFLOWNVQTA/view?usp=sharing https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZZV... And the git access timings are a sea of red https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZTzg3NFN4UXU3Qmc/view?usp=sharing https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZTz... Git access will be improved now that we have Gitaly as part of this release. In GitLab 9.1 we want to move git access from the application server to the file server. That should greatly reduce the latency.
  - tokenizerrr 10y ago
    Can't access any of those links, just get a login prompt.
    - zegerjan 10y ago
      That is the internal one, Sid meant to link to the public monitoring, located at http://monitor.gitlab.net/ http://monitor.gitlab.net/. It doesn't have the daily overview dashboard, but the fleet overview might be an indicator too (http://monitor.gitlab.net/dashboard/db/fleet-overview http://monitor.gitlab.net/dashboard/db/fleet-overview).
    - sytse 10y ago
      Sorry about that, we've replaced the links with screenshots. The problem is that we can't measure Unicorn timings with Prometheus since it is multi-process. Our Prometheus team is working to fix this for everyone.
  - superplussed 10y ago
    I'm glad this is a priority for you guys Sid, the one thing keeping me from using Gitlab is that it doesn't feel as snappy as Github. But as a point of reference, I'm also a guy that won't use Atom because it doesn't feel as snappy as Sublime. For some of us, speed comes first.
- victorwu 10y ago
  The ongoing discussion regarding the sidebar/navigation is here: https://gitlab.com/gitlab-org/gitlab-ce/issues/29835 https://gitlab.com/gitlab-org/gitlab-ce/issues/29835. Thanks again for the feedback.
  - buxtehude 10y ago
    What's sad is that this isn't the first time GitLab UX/UI peeps have tried to remove the sidebar. 9 months ago we went through a very similar version of this: https://gitlab.com/gitlab-org/gitlab-ce/issues/18542 https://gitlab.com/gitlab-org/gitlab-ce/issues/18542 Can we just all agree to keep the damn sidebar available - if UX wants to remove it, fine, as long as users have the ability to easily permanently pin it back open if they wish to do so. By now GitLab UX should realize that enough developers find great utility in that sidebar.
    - allover 10y ago
      Perhaps the 'sad'/'damn sidebar'/'should realize' passive-aggressive entitlement doesn't help?
      - stonogo 10y ago
        Yes, I'm sure Gitlab's engineers make technical decisions based on this guy's tone in Hacker News comments.
        zachsnow 10y ago
        Maybe they just feel bad when they are going to sleep.
        allover 10y ago
        His tone almost guarantees his complaint won't be take seriously. Also, just being nice is a generally good principle.
    - buxtehude 10y ago
- deleted 10y ago
  [deleted]
jhasse 10y ago
No more fixed header and pages properly reload when I click on a link (spinning icon in the tab). Awesome! These were my major UI gripes in GitLab 8.
- sytse 10y ago
  Awesome! This is because we removed turbolinks https://about.gitlab.com/2017/02/06/vue-big-plan/ https://about.gitlab.com/2017/02/06/vue-big-plan/
tomc1985 10y ago
Gitlab was really promising for my colleagues and I, but its inability to host git repos on the url root (aka gitrepo.mycompany.com/product.git) without hacking means its a no-go as we're not particularly inclined to redo all our development, deployment, and testing infrastructure. We use git a lot in our organization, including customer-facing stuff, so it would be a large transition. Also stubborn coworkers who don't want to monkey with git settings. Which is a shame, I really like gitlab and would love to replace gitolite :/
- frikk 10y ago
  What if you just set up an nginx reverse proxy? gitrepo.mycompany.com/product.git --> reverse proxy to git.mycompany.com/gitrepo/product.git Should be straight forward in nginx
  - ykler 10y ago
    Just curious since I am not experienced with this stuff, are you talking about a TCP reverse proxy (so it could work with the SSH protocol too)? And would haproxy work equally well to nginx for this?
    - ianleeclark 10y ago
      If I remember right, nginx doesn't support ssh + http(s) on the same port. I'd be happy to learn this isn't correct, though because my personal server only is allowing http through.
      - tomc1985 10y ago
        Generally speaking, you cannot bind more than one service to a port on a given interface
        ianleeclark 10y ago
        Yeah, that's the issue i had ran into. I was `listen`ing on 80, but wanted to multiplex ssh+http on the same port and nginx didn't support it.
kozikow 10y ago
What convinced me to try out gitlab today: "Today with 9.0, we are excited to release Deploy Boards for environments running on Kubernetes. The Environments page of Pipelines now offers a single place to view the current health and deployment status of each environment, displaying the specific status of each pod in the deployment. Developers and other teammates can view the progress and status of a rollout, pod by pod, in the workflow they already use without any need to access Kubernetes."
- sytse 10y ago
  Great to hear that. Deploy boards is one of the few features that came from our own vision more than customer requests. So we're very happy to get validation that this is something people need. GitLab 9.1 will have canary deploys and an automatically deploy board to make deployments even better.
  - josegonzalez 10y ago
    Is there an api for users that might want to integrate alternative schedulers for these features? Would be lovely to be able to integrate Nomad somewhat natively.
    - sytse 10y ago
      Right now Kubernetes is a project service in GitLab. We would love to have a project service for Nomad to do the same. Right now we're focussed on Kubernetes but we hope the wider community will pick up the other schedulers. Also see https://about.gitlab.com/strategy/ https://about.gitlab.com/strategy/ "The people that have the most knowledge have to prioritize breadth over depth since only they can add new functionality. Making the functionality more comprehensive requires less coordination than making the initial minimal feature. Shipping functionality that is incomplete to expand the scope sometimes goes against our instincts. However leading the way is needed to allow others to see our path and contribute. So when in doubt, the rule of thumb is breadth over depth, so everyone can contribute."
    - jobvandervoort 10y ago
darkengine 10y ago
I would love to upgrade on my GitLab server, but I haven't been able to build GitLab with the omnibus builder since 8.14. I opened up a ticket but it hasn't garnered a response. https://gitlab.com/gitlab-org/gitlab-omnibus-builder/issues/7 https://gitlab.com/gitlab-org/gitlab-omnibus-builder/issues/...
- jobvandervoort 10y ago
  It seems the issue is on the wrong issue tracker. Our omnibus lead Marin will make sure that it lands in the right place and gets some attention (see the comment from ZJ). Edit: more info in the issue you've posted.
jrobn 10y ago
I've looked at their website. Is Gitlab basically a self hosted Github and Heroku style (app containers) like product?
- connorshea 10y ago
  We have open source self-hosted (Community Edition), open core self-hosted (Enterprise Edition), or hosted (GitLab.com). It's more like GitHub + Chat + CI + CD + Heroku + New Relic (early stages). Where Heroku forces you to use their platform, GitLab allows you to use any platform that runs Kubernetes.
- lotyrin 10y ago
  If you host it on top of a Kubernetes cluster, yes. Github (including kanban boards) + CI + Heroku (including deployments, workflows) + now even Monitoring. They are selling what one might call an "Omakase" experience for the whole SDLC. They call it "Idea to Production".
  - Snappy 10y ago
    Thanks for that, lotryn, that might be my favorite quote today.
  - sytse 10y ago
    That is a very apt description, thank you for that. We're really inspired by the Rails doctrine http://rubyonrails.org/doctrine/ http://rubyonrails.org/doctrine/ and think that the Software Development LifeCycle (SDLC) has room for a solution with convention over configuration.
deleted 10y ago
[deleted]
psankar 10y ago
Any documentation / talks / videos about the gitlab + kubernetes integration ? Thanks for the awesome product. At work we switched to gitlab for new projects and loving.
- connorshea 10y ago
  Thanks for switching to GitLab, glad to hear you're loving it! :D We have this demo from our most recent summit where we put together an entire GitLab instance in ~20 minutes on a Kubernetes cluster, though I'm not sure that's exactly what you want? https://about.gitlab.com/2017/01/23/video-tutorial-idea-to-production-on-google-container-engine-gke/ https://about.gitlab.com/2017/01/23/video-tutorial-idea-to-p... We also have some documentation on integrating with Kubernetes here: https://docs.gitlab.com/ee/user/project/integrations/kubernetes.html#gitlab-kubernetes-openshift-integration https://docs.gitlab.com/ee/user/project/integrations/kuberne...
  - ianwalter 10y ago
    The integration with Kubernetes looks pretty cool so far. Is there any consideration being given to integrating with Docker Swarm Mode?
    - Snappy 10y ago
      We're hoping to work with the community to support all container schedulers [1]. But right now we're focused on deepening the integration on Kubernetes so it's a great end-to-end experience. [1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/20199 https://gitlab.com/gitlab-org/gitlab-ce/issues/20199
    - sytse 10y ago
      Please see my other comment https://news.ycombinator.com/item?id=13932591 https://news.ycombinator.com/item?id=13932591
- Snappy 10y ago
  The video in the blog post is all on Kubernetes as well, ans shows off terminal, deploy boards, and monitoring; all on Kubernetes. It doesn't go into detail, of course, but it's great if you just want to see it.
danial 10y ago
Congratulations on shipping 9.0. It's great to see a lot of improvements. Being able to reorder issues in the board is a welcome change. The subgroups is an interesting feature. I look forward to playing with it more. I am still waiting on the ability to view issues on a board across a group (or now, a subgroup). Since Gitlab projects are repo-centric, I have hard time tracking issues across many repositories in a single place. A board that is visible at a group-level would solve this problem. I believe this is a feature that's coming soon, though. I am looking forward to it.
- microcolonel 10y ago
  Not that this is a solution everywhere, but I'm always telling people that single-repo is the way to go for an integrated team. My rule is that if your business unit can reasonably control a codebase, and you have access to it, it should be in the same repo as your other codebases, full-stop. I've seen too many npm messes where people obsess over putting every button, dropdown, heading, and dumb image component in its own company-specific repo. Then they put the whole thing in a "UI kit" which realistically they will never reuse.
  - bryanlarsen 10y ago
    Yup, I think Google & Facebook have this one right, a mono-repo is the way to go. But there are advantages to multi-repos, especially if you're trying to share with clients and/or open source. You can have your cake and eat it too: we use https://github.com/splitsh/lite https://github.com/splitsh/lite to update our micro-repos on every commit to our monorepo.
  - victorwu 10y ago
    We originally built GitLab with that use case of a single repo in mind. Create a GitLab project, and you have a single repository for code. We know this is an important use case for many teams, because of it's straightforward, simple scenario. It's something that's important to us, even as we expand to other use cases of multi-repo teams (groups/subgroups housing of projects). Thanks for the comment.
- 10y ago
nik736 10y ago
As much as I love GitLab the UI/UX is still very weak compared to GitHub. And the sidebar change is something in the completely wrong direction. You should also really check out how it looks on a 4k screen.
- GordonS 10y ago
  Well, IMO the Github UI has been taking some steps backwards recently. If Gitlab keeps improving and Github worsening, they'll be at parity before too long
  - MartinCron 10y ago
    That's not the way to reach parity!
  - sytse 10y ago
    We certainly don't want to win in a race to the bottom. To get an idea what our UX team is working on please see their update from this Monday: Video https://www.youtube.com/watch?v=TMdw-plNfDQ https://www.youtube.com/watch?v=TMdw-plNfDQ Slides https://docs.google.com/presentation/d/1LM6wHxGVRwHwQvGJiXwF_HEsbP8OEfW3p6WbdNSkozU/edit?usp=sharing https://docs.google.com/presentation/d/1LM6wHxGVRwHwQvGJiXwF...
    - GordonS 10y ago
      I imagined you'd meet in the middle, rather than at the bottom! I like what you guys are doing - my comment was more meant as a well-natured jibe against the recent Github changes, which I'm really struggling to like (the black header a few weeks ago, and today the search results interface).
      - sytse 10y ago
        Ah, sorry for misreading it, I get caught up in the release excitement. <3
- victorwu 10y ago
scott_karana 10y ago
For anybody else wondering where that gorgeous cover photo is from: Queenstown, New Zealand :-) https://about.gitlab.com/images/9_0/9_0-cover-image.jpeg https://about.gitlab.com/images/9_0/9_0-cover-image.jpeg https://www.google.ca/search?q=queenstown+new+zealand&source=lnms&tbm=isch https://www.google.ca/search?q=queenstown+new+zealand&source...
hmottestad 10y ago
Anyone know where that restaurant in the picture is? Looks amazing!
- hmottestad 10y ago
  Found it: https://www.omegarentalcars.com/support/blog/queenstown-luge-and-skyline-gondola/ https://www.omegarentalcars.com/support/blog/queenstown-luge...
- timack 10y ago
  http://www.skyline.co.nz/queenstown/restaurant/ http://www.skyline.co.nz/queenstown/restaurant/
apocalyptic0n3 10y ago
With the focus on performance, is there any chance we could get pagination on the deploy keys page? Our company is self hosting the CE version and we currently have 339 deployment keys. Every time we need to load the deployment keys page, it takes upwards of 20s. We could probably organize things differently and cut that down, but that would be a significant restructure and time investment for what would essentially be a band-aid. I (and others) have requested it before, but was told it was too low of a priority and it wouldn't be worked on.
- connorshea 10y ago
  I can't find an issue for this specifically, could you open one so we can get it tracked? https://gitlab.com/gitlab-org/gitlab-ce/issues https://gitlab.com/gitlab-org/gitlab-ce/issues
  - apocalyptic0n3 10y ago
    The previous suggestions were done on the old suggestion site and I cannot find a link to that site anymore; it's been a while since I have personally brought it up but noticed all the mentions of performance improvements and, combined with our ever-growing list of keys, it felt like something to bring up again. @zegerjan made a ticket for it, but it's already been closed by Stan because it is being tracked by some general performance ticket. https://gitlab.com/gitlab-org/gitlab-ce/issues/29861 https://gitlab.com/gitlab-org/gitlab-ce/issues/29861
- zegerjan 10y ago
  I've opened an issue, as I couldn't find another. https://gitlab.com/gitlab-org/gitlab-ce/issues/29861 https://gitlab.com/gitlab-org/gitlab-ce/issues/29861 If we have it profiled we can give it the right priority.
- flavor8 10y ago
  Pagination on the list of commits in a PR would be awesome also. Oftentimes a week of work that's bundled in our develop->master RC merge will have more than 100 commits. Gitlab _only_ displays 100, and doesn't let you see the rest; since I like to skim down the commit messages to make release notes for the RC, this is pretty inconvenient.
tracker1 10y ago
I'm surprised, impressed, and frankly amused in that you can sign into gitlab.com with your github account.
- jobvandervoort 10y ago
  Glad to hear that. You can also import your projects directly (everything will be copied over). We don't see any reason for you not to do so. GitLab should be the easiest place to get started. If that means logging in with GitHub, we're happy to make that possible.
  - Nadya 10y ago
    >You can also import your projects directly (everything will be copied over). I had forgotten about that, thanks for the reminder. I'll be moving all my stuff over this weekend once I curate out the things I don't actually use over on Github...
- YCode 10y ago
  They know their audience, I suppose. Anyway it makes importing projects easier.
- hackerboos 10y ago
  That's how I exported all my private Github projects and cancelled my pro account.
itwy 10y ago
The sidebar took a step backward in my opinion. I am missing the 'pin' option.
- victorwu 10y ago
  Thanks. Feel free to add feedback to the ongoing discussion here: https://gitlab.com/gitlab-org/gitlab-ce/issues/29835 https://gitlab.com/gitlab-org/gitlab-ce/issues/29835.
  - buxtehude 10y ago
    Why did you remove the sidebar + pin again?? When you removed the sidebar last time - users of GitLab lobbied you hard to get that pin in there so they could keep that sidebar open at all times. These kind of changes make me feel like you're not understanding (respecting) your customers' needs (desires).
    - buxtehude 10y ago
      Sorry just to be clear - I really like GitLab - and I feel GitLab tries hard to make a great product for their users - and clearly they have a good understanding of the development community. It's just that I felt this issue had already been discussed and resolved - to be yet again undone. So just feeling frustrated we have to go through this again.
deleted 10y ago
[deleted]
machbio 10y ago
how is the CD in Gitlab complete without this issue being complete (https://gitlab.com/gitlab-org/gitlab-ce/issues/28497 https://gitlab.com/gitlab-org/gitlab-ce/issues/28497) - is there any alternative if i want to use "gitlab.com" for hosting my code ?
- sytse 10y ago
  Most of CD including deployments already works for private projects, it is only the auto deploy https://docs.gitlab.com/ee/ci/autodeploy/index.html https://docs.gitlab.com/ee/ci/autodeploy/index.html that doesn't work yet. We would all like to see auto deploy working with private projects and it is scheduled for 9.1 If you don't want to use GitLab.com to host your code you can install GitLab yourself or use the mirroring function in GitLab to deploy code hosted elsewhere.
  - machbio 10y ago
    will just wait for "Gitlab.com" to get the functionality - is there any lag between Gitlab version upgrade and "Gitlab.com" using the upgraded Gitlab version ? Will wait it out for Gitlab 9.1 :) Thank you for the amazing work.
    - sytse 10y ago
      GitLab.com has RCs weeks before the official release. And you're welcome.
garou 10y ago
I am having problem with de CI/CD after update: ``` Running with gitlab-ci-multi-runner 9.0.0[...] Cloning repository... Cloning into '/builds/xxxxxxx'... warning: You appear to have cloned an empty repository. Checking out xxxxxxx as master... fatal: reference is not a tree: xxxxxx ```
- garou 10y ago
  I rebooted de entire machine and it is working now
  - sytse 10y ago
    Thanks for reporting back, glad to hear it is working now.
- tmaczukin 10y ago
  For other who are seeing this issue: 'gitlab-ctl reconfigure && gitlab-ctl restart' should resolve this problem without a need to reboot the machine. The problem is tracked in https://gitlab.com/gitlab-org/gitlab-ce/issues/29855 https://gitlab.com/gitlab-org/gitlab-ce/issues/29855
jancsika 10y ago
I love and use Gitlab and am excited about the 9.0 performance improvements. On the other hand, I found it absurdly difficult to get feedback or action from Gitlab on an MR. There was an MR that fixed a critical problem in the virtualbox runner, and it sat there for about 5 months with no response to either the original submitter or my emails to gitlab/gitlab ci maintainers. About a month ago I finally decided to abuse your customer support addy to ask if somebody could force the maintainer to respond before the code rots. By that time the original submitter (who in comparison turned out to be easy to contact and collaborate with) was long gone. And another user had already announced a separate script they developed and maintained to work around the lack of merging this fix. I'm glad it finally got merged, but it was only after deciding to use my free time and treat the process as a kind of game to be beaten. But that's a one-off game I won't play again. Plus I doubt the original submitter, a Go developer, will be making another merge request. Anyhow, I made a list on the relevant issue tracker of the work it took to get the maintainer to eventually click the "merge" button: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_requests/313 https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_r...
- ayufan 10y ago
  Hi janciska, Thanks for writing that comment and making us aware of that case. I'm very sorry that it did that long to get reviewed and merged. The number of issues and merge requests that pass our hands is just crazy and sometimes it happens that some of them are oversight and not properly scheduled. Having people to be persistent, like you, makes them finally to be merged and be part of the product. Thank you for doing that! From our side, we will try our best to make this process to be more efficient. Kamil, CI/CD Lead at GitLab
  - dataops 10y ago
    Kamil, Can GitLab have a hands-on demo at the upcoming DataOps Summit in Boston? https://www.dataopssummit.com/ https://www.dataopssummit.com/
  - jancsika 10y ago
    Hi Kamil, Thanks for the reply. One point may not have been clear-- this isn't just a matter of a single bugfix being available to the userbase sooner rather than later. Rather, it is that multiple iterations through a development cycle were missed. From my rough recollection: 1. There was a problem setting up an OSX guest to work with virtualbox runner on OSX with passwords. We worked around this using pubkey-based auth between guest and host. 2. There was also a timeout issue mentioned on the tracker for which Sam found the relevant code and suggested (but did not create) a fix. 3. Sam seemed to think a snapshot-reuse approach was too complex and likely to hang or fail. I didn't agree and was trying to explore ways in which they could run reliably as it cut CI time in half for my use case. 4. For uploading artifacts, the OSX guest's gitlab-runner binary had the wrong name requiring the user to manually create a symlink with the correct name. (I think this is fixed in 9.0, but not sure since I still have the symlink there and it's still working.) At the time my CI builds (and probably Sam's) weren't working at all, so we both ate the cost of learning how the CI build system worked in order to debug it. If there had been feedback saying that his MR was the right (or wrong) approach I would have been happy to apply my knowledge gained at the time to the related problems mentioned above in order to debug and eventually fix them. But now that knowledge is gone. The cost for me to regain it outweighs the benefits of small improvements to what is atm a working if imperfect system. Edit: formatting
chetanahuja 10y ago
The new enhancements seem very promising. We've been using gitlab for our internal use for a while now. Having said that, every time a new gitlab release comes around, I always looks for updates in one area expectantly but mostly left unsatisfied. And that is, separation of the concept of Project from "one git repo" E.g., I want to manage a project that ties in issues from various different git repositories. It's pretty common. Almost no actual "project" in a real life business is limited to just one git repo. I want a system-wide wiki that collects knowledge about the entire operations. The idea that each wiki is tied to a particular git-repo is.. just... wrong. Heck, even the new search feature across projects somehow doesn't include wiki's. How did that decision get made? And so on and so forth.
- jobvandervoort 10y ago
  One of the high level goals I set for this year is scaling up to projects that consist of more than a single repository. That means CI that spans multiple projects [0], higher abstraction of issue management [1], formal relationships between issues [2] and more. Having a global wiki or higher level wiki should also be part of that [3], I think. [0]: https://gitlab.com/gitlab-org/gitlab-ee/issues/933 https://gitlab.com/gitlab-org/gitlab-ee/issues/933 [1]: https://gitlab.com/gitlab-org/gitlab-ee/issues/928 https://gitlab.com/gitlab-org/gitlab-ee/issues/928 [2]: https://gitlab.com/gitlab-org/gitlab-ce/issues/4058 https://gitlab.com/gitlab-org/gitlab-ce/issues/4058 [3]: https://gitlab.com/gitlab-org/gitlab-ce/issues/4037 https://gitlab.com/gitlab-org/gitlab-ce/issues/4037
jbk 10y ago
We've been using gitlab for most VideoLAN projects, and are moving towards it for all of them (including vlc and x264). A lot of things are great, and going in the right direction, but the issues tracker is really lacking. The lack of custom fields, that you find in all other bugtrackers except github, and the lack of dependent issues are really blocking us to move full to gitlab. And the biggest issue is that they're discussing to do it, but only in the non-open-source version, which we cannot use...
- sytse 10y ago
  Thanks for using GitLab. We have open sourced features based on your request before https://news.ycombinator.com/item?id=10931690 https://news.ycombinator.com/item?id=10931690 I can't promise anything regarding these features. Especially custom fields are a typical EE feature in our perspective. The dependent issues feature proposal https://gitlab.com/gitlab-org/gitlab-ce/issues/4058#note_24946893 https://gitlab.com/gitlab-org/gitlab-ce/issues/4058#note_249... is still on the CE tracker but I'm not sure what it's future is.
  - jbk 10y ago
    Don't take me badly, Gitlab is the best thing around. We've tested many solutions... (too many) It's just that I really want to quit using trac, who is slow and not integrated with the rest of the infrastructure.
    - sytse 10y ago
      No worries, we love you too! Our Product Manager Victor Wu will email you to learn more.
- deleted 10y ago
  [deleted]
- victorwu 10y ago
  You are referring to this one right? https://gitlab.com/gitlab-org/gitlab-ee/issues/1906 https://gitlab.com/gitlab-org/gitlab-ee/issues/1906. Yes, it is currently marked as an EE feature. And Sid linked to the dependent issues feature below. Both of these features are not scheduled for development yet. We scope work out month to month, so we can't promise anything regarding those at this time. But we are discussing them as you see in the issues and considering how they would fit into our product as we recognize they are important features for many teams. For relations between issues, we are considering various designs, such as: https://gitlab.com/gitlab-org/gitlab-ee/issues/1941 https://gitlab.com/gitlab-org/gitlab-ee/issues/1941 and https://gitlab.com/gitlab-org/gitlab-ce/issues/29444 https://gitlab.com/gitlab-org/gitlab-ce/issues/29444.
imsodrunklol 10y ago
Jesus, they're killing it.
nik736 10y ago
You guys should look into your search functionality as it's not working for hours already :)
HankB99 10y ago
I wonder if this will provide a benefit in a resource constrained environment. I run the official Gitlab Docker/gitlab-ce container in a host with a J1900 processor and 4GB RAM and it is barely usable. Most pages timeout on the first load. At present it looks like it hasn't been updated since 2015.
- dijit 10y ago
  Currently running gitlab over docker on a dedicated 8 core system with 32G of ram, it routinely uses 9G of that for barely 30 users. (it's the only thing running on that physical host) So, keep that in mind.
  - AlexCoventry 10y ago
    Which version of gitlab? Didn't they reduce memory demands in a recent release?
    - dijit 10y ago
      I keep it updated; it's now version 9 and still consuming 7G total used free shared buffers cached Mem: 31974 13984 17989 12 871 6047 -/+ buffers/cache: 7066 24907 Swap: 16367 The UI counts 10G for some reason. http://i.imgur.com/edAceQx.png http://i.imgur.com/edAceQx.png
      - brodock 10y ago
        Our omnibus package tries to use a % of your total memory for cache, so one way to reduce memory is fine tuning it. See for reference: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/attributes/default.rb#L373-380 https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/fil...
the_common_man 10y ago
Awesome release! What do people use to keep up to date with all the non-stop Gitlab releases? I used to use sandstorm but their port is very outdated by now (same goes for bitnami). I switched to cloudron and it has served me well but I am always on the look out for other solutions. On a side note, if you use the omnibus packages, are you a full time (or even part-time) sysadmin?
- nsomaru 10y ago
  Using omnibus (with backups), it's as simple as an 'aptitude upgrade' for us
  - the_common_man 10y ago
    Have you just setup a cronjob for backups? And do you also test somehow that those backups work (or rely on gitlab doing the right thing?) Or maybe you use server snapshots? Also how how did you go about SSL?
teekert 10y ago
I like Gitlab, as an absolute noob I'm not really ready to make every mess of a program I use public (as Github requires). I fear that it can and will be used against me. I'm also such a small time user I think paying for Github is too much for my 3 > 200 lines projects. And so you end up at Gitlab. It works very well for me. If I want to, in the future, I can host it myself which is a nice thing. From this update I most like the dark-themed code view, yes I'm a simple man that is just learning how to code.
hpio 10y ago
Any idea how I can upgrade my docker installation on Kubernetes? At the moment in my Helm chart i have specified exat Gitlab and Postgresql version. Do i need to bump postgresql too when changing Gitlab?
maktouch 10y ago
Ah! Finally found the culprit :-) I run my fleet of runners in pre-emptible instances on GCP (they die after 24h). I forgot to pin the version in my startup script, so all it did was a simple apt-get install gitlab-ci-multi-runner. For some reason, version 9 of the gitlab runner cannot connect to our Gitlab (it fires a 404 on register). Anyways, look like 9 is a cool release, but we won't be upgrading until the sidebar comes back (did a little poll in the team and it 100% was in favour of the sidebar)
- tmaczukin 10y ago
  maktouch: Runner can't connect to GitLab because version 9.0 of Runner requires GitLab 9.0. We've noticed this in the release blog post: https://about.gitlab.com/2017/03/22/gitlab-9-0-released/#gitlab-runner-deprecation https://about.gitlab.com/2017/03/22/gitlab-9-0-released/#git... :) The reason is that in 9.0 we've prepared a new API for Runner requests (as part of new v4 version of API) and Runner 9.0 is using only this version. Version v1 of the CI API is still supported by Runner 1.10.X and 1.11.X. On GitLab's side it will be supported until August 2017 and until then we will also support Runner 1.11.X.

deleted 10y ago

[deleted]

The performance improvements are very noticeable : general page load times, pushing code to gitlab is as fast as github now and the commit messages load insanely fast, compared to a few months ago where loading commit messages in the UI used to take at least a couple of seconds. I don't follow gitlab development too closely, but they seem to have focused a lot on improving cache performance. But one change that I did not like was the the removal of the side panel which could be pinned. Navigation required fewer steps, but now an extra click is required to bring up the options.

victorwu 10y ago
Thanks for the feedback regarding the sidebar navigation! Here's the issue that we used to chat extensively about it and came to our current design here in 9.0: https://gitlab.com/gitlab-org/gitlab-ce/issues/26200 https://gitlab.com/gitlab-org/gitlab-ce/issues/26200 There's lots of discussion there. We went with a design that leans on getting out of your way and recovers some screen real-estate. We do recognize the one additional click required though. And we are actively listening to feedback and will continue to iterate. We're working hard to improve usability and navigation in general. In addition to this sidebar change, we've made many nav updates: https://gitlab.com/gitlab-org/gitlab-ce/issues/26348 https://gitlab.com/gitlab-org/gitlab-ce/issues/26348.
- tokenizerrr 10y ago
  Trading usability for screen real-estate? Sounds like your designers have gone off the deep end and fail to realize that Gitlab is a productivity tool, not an art piece.
  - connorshea 10y ago
    I'd argue that extra screen real estate for the content that matters often lends itself toward better UX, but any specific suggestions for improvements would be appreciated. :)
  - thoughtpalette 10y ago
    That's quite a bold statement from an armchair UX designer. They obviously have reasoning and supporting data, maybe you're in the minority of users who've found that useful?
  - victorwu 10y ago
    Thanks for the feedback! In this iteration, we think recovering more space helps users focus on content, and allows them to see more content at once. Definitely we recognize the tradeoff of additional clicks and discoverability as a result. We are definitely focused on usability, and navigation in general. We don't claim to know all the right answers all the time. So we are iterating with each release, and working hard doing user research as well to inform our decisions. You can see some of our recent work regarding nav here: https://gitlab.com/gitlab-org/ux-research/issues/3 https://gitlab.com/gitlab-org/ux-research/issues/3. Thanks.
- tracker1 10y ago
  The application I'm working on, I went with a 3-state navigation... null (default), true (open) or false (closed) ... at large screen sizes null is a soft open, smaller soft closed... toggling goes between the respective hard state and the null/default state. At sm-medium, it's an overlay, at phone/xs it takes over the screen. I find that this is more intuative to use than a hard on/off only.
- wjoe 10y ago
  I agree with the parent about the sidebar. I already disliked the change to make it hidden by default with the pin option since it was a bit inconsistent for me, but it at least gave the option for best of both worlds. Ideally this should be an option. I get that 'modern UX' is all about more screen space and whatnot, but I'm not a fan of that trend personally. It seems that all that's been gained from that change is more empty space at the side of pages. Personally, I'm the type that would rather have more information and convenience on the page than extra space. Would it be that hard to add an option to enable the side bar if people want it? That's what I like about GitLab, that it's very configurable.
sytse 10y ago
Great to hear you notice the performance improvements. We're very happy with the improvements but we still have long way to go. We want the 99% latency under 1s and right now it is 2s: https://drive.google.com/file/d/0BzQDcBnEfNRZSTZYVXlyc1FGdEk/view https://drive.google.com/file/d/0BzQDcBnEfNRZSTZYVXlyc1FGdEk... There are some controller timings that are red https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZZVZiRXFLOWNVQTA/view?usp=sharing https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZZV... And the git access timings are a sea of red https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZTzg3NFN4UXU3Qmc/view?usp=sharing https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZTz... Git access will be improved now that we have Gitaly as part of this release. In GitLab 9.1 we want to move git access from the application server to the file server. That should greatly reduce the latency.
- tokenizerrr 10y ago
  Can't access any of those links, just get a login prompt.
  - zegerjan 10y ago
    That is the internal one, Sid meant to link to the public monitoring, located at http://monitor.gitlab.net/ http://monitor.gitlab.net/. It doesn't have the daily overview dashboard, but the fleet overview might be an indicator too (http://monitor.gitlab.net/dashboard/db/fleet-overview http://monitor.gitlab.net/dashboard/db/fleet-overview).
  - sytse 10y ago
    Sorry about that, we've replaced the links with screenshots. The problem is that we can't measure Unicorn timings with Prometheus since it is multi-process. Our Prometheus team is working to fix this for everyone.
- superplussed 10y ago
  I'm glad this is a priority for you guys Sid, the one thing keeping me from using Gitlab is that it doesn't feel as snappy as Github. But as a point of reference, I'm also a guy that won't use Atom because it doesn't feel as snappy as Sublime. For some of us, speed comes first.
victorwu 10y ago
The ongoing discussion regarding the sidebar/navigation is here: https://gitlab.com/gitlab-org/gitlab-ce/issues/29835 https://gitlab.com/gitlab-org/gitlab-ce/issues/29835. Thanks again for the feedback.
- buxtehude 10y ago
  What's sad is that this isn't the first time GitLab UX/UI peeps have tried to remove the sidebar. 9 months ago we went through a very similar version of this: https://gitlab.com/gitlab-org/gitlab-ce/issues/18542 https://gitlab.com/gitlab-org/gitlab-ce/issues/18542 Can we just all agree to keep the damn sidebar available - if UX wants to remove it, fine, as long as users have the ability to easily permanently pin it back open if they wish to do so. By now GitLab UX should realize that enough developers find great utility in that sidebar.
  - allover 10y ago
    Perhaps the 'sad'/'damn sidebar'/'should realize' passive-aggressive entitlement doesn't help?
    - stonogo 10y ago
      Yes, I'm sure Gitlab's engineers make technical decisions based on this guy's tone in Hacker News comments.
      - zachsnow 10y ago
        Maybe they just feel bad when they are going to sleep.
      - allover 10y ago
        His tone almost guarantees his complaint won't be take seriously. Also, just being nice is a generally good principle.
  - buxtehude 10y ago
deleted 10y ago
[deleted]

jhasse 10y ago

No more fixed header and pages properly reload when I click on a link (spinning icon in the tab). Awesome! These were my major UI gripes in GitLab 8.

sytse 10y ago
Awesome! This is because we removed turbolinks https://about.gitlab.com/2017/02/06/vue-big-plan/ https://about.gitlab.com/2017/02/06/vue-big-plan/

tomc1985 10y ago

Gitlab was really promising for my colleagues and I, but its inability to host git repos on the url root (aka gitrepo.mycompany.com/product.git) without hacking means its a no-go as we're not particularly inclined to redo all our development, deployment, and testing infrastructure. We use git a lot in our organization, including customer-facing stuff, so it would be a large transition. Also stubborn coworkers who don't want to monkey with git settings. Which is a shame, I really like gitlab and would love to replace gitolite :/

frikk 10y ago
What if you just set up an nginx reverse proxy? gitrepo.mycompany.com/product.git --> reverse proxy to git.mycompany.com/gitrepo/product.git Should be straight forward in nginx
- ykler 10y ago
  Just curious since I am not experienced with this stuff, are you talking about a TCP reverse proxy (so it could work with the SSH protocol too)? And would haproxy work equally well to nginx for this?
  - ianleeclark 10y ago
    If I remember right, nginx doesn't support ssh + http(s) on the same port. I'd be happy to learn this isn't correct, though because my personal server only is allowing http through.
    - tomc1985 10y ago
      Generally speaking, you cannot bind more than one service to a port on a given interface
      - ianleeclark 10y ago
        Yeah, that's the issue i had ran into. I was `listen`ing on 80, but wanted to multiplex ssh+http on the same port and nginx didn't support it.

kozikow 10y ago

What convinced me to try out gitlab today: "Today with 9.0, we are excited to release Deploy Boards for environments running on Kubernetes. The Environments page of Pipelines now offers a single place to view the current health and deployment status of each environment, displaying the specific status of each pod in the deployment. Developers and other teammates can view the progress and status of a rollout, pod by pod, in the workflow they already use without any need to access Kubernetes."

sytse 10y ago
Great to hear that. Deploy boards is one of the few features that came from our own vision more than customer requests. So we're very happy to get validation that this is something people need. GitLab 9.1 will have canary deploys and an automatically deploy board to make deployments even better.
- josegonzalez 10y ago
  Is there an api for users that might want to integrate alternative schedulers for these features? Would be lovely to be able to integrate Nomad somewhat natively.
  - sytse 10y ago
    Right now Kubernetes is a project service in GitLab. We would love to have a project service for Nomad to do the same. Right now we're focussed on Kubernetes but we hope the wider community will pick up the other schedulers. Also see https://about.gitlab.com/strategy/ https://about.gitlab.com/strategy/ "The people that have the most knowledge have to prioritize breadth over depth since only they can add new functionality. Making the functionality more comprehensive requires less coordination than making the initial minimal feature. Shipping functionality that is incomplete to expand the scope sometimes goes against our instincts. However leading the way is needed to allow others to see our path and contribute. So when in doubt, the rule of thumb is breadth over depth, so everyone can contribute."
  - jobvandervoort 10y ago

darkengine 10y ago

I would love to upgrade on my GitLab server, but I haven't been able to build GitLab with the omnibus builder since 8.14. I opened up a ticket but it hasn't garnered a response. https://gitlab.com/gitlab-org/gitlab-omnibus-builder/issues/7 https://gitlab.com/gitlab-org/gitlab-omnibus-builder/issues/...

jobvandervoort 10y ago
It seems the issue is on the wrong issue tracker. Our omnibus lead Marin will make sure that it lands in the right place and gets some attention (see the comment from ZJ). Edit: more info in the issue you've posted.

jrobn 10y ago

I've looked at their website. Is Gitlab basically a self hosted Github and Heroku style (app containers) like product?

connorshea 10y ago
We have open source self-hosted (Community Edition), open core self-hosted (Enterprise Edition), or hosted (GitLab.com). It's more like GitHub + Chat + CI + CD + Heroku + New Relic (early stages). Where Heroku forces you to use their platform, GitLab allows you to use any platform that runs Kubernetes.
lotyrin 10y ago
If you host it on top of a Kubernetes cluster, yes. Github (including kanban boards) + CI + Heroku (including deployments, workflows) + now even Monitoring. They are selling what one might call an "Omakase" experience for the whole SDLC. They call it "Idea to Production".
- Snappy 10y ago
  Thanks for that, lotryn, that might be my favorite quote today.
- sytse 10y ago
  That is a very apt description, thank you for that. We're really inspired by the Rails doctrine http://rubyonrails.org/doctrine/ http://rubyonrails.org/doctrine/ and think that the Software Development LifeCycle (SDLC) has room for a solution with convention over configuration.

deleted 10y ago

[deleted]

psankar 10y ago

Any documentation / talks / videos about the gitlab + kubernetes integration ? Thanks for the awesome product. At work we switched to gitlab for new projects and loving.

connorshea 10y ago
Thanks for switching to GitLab, glad to hear you're loving it! :D We have this demo from our most recent summit where we put together an entire GitLab instance in ~20 minutes on a Kubernetes cluster, though I'm not sure that's exactly what you want? https://about.gitlab.com/2017/01/23/video-tutorial-idea-to-production-on-google-container-engine-gke/ https://about.gitlab.com/2017/01/23/video-tutorial-idea-to-p... We also have some documentation on integrating with Kubernetes here: https://docs.gitlab.com/ee/user/project/integrations/kubernetes.html#gitlab-kubernetes-openshift-integration https://docs.gitlab.com/ee/user/project/integrations/kuberne...
- ianwalter 10y ago
  The integration with Kubernetes looks pretty cool so far. Is there any consideration being given to integrating with Docker Swarm Mode?
  - Snappy 10y ago
    We're hoping to work with the community to support all container schedulers [1]. But right now we're focused on deepening the integration on Kubernetes so it's a great end-to-end experience. [1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/20199 https://gitlab.com/gitlab-org/gitlab-ce/issues/20199
  - sytse 10y ago
    Please see my other comment https://news.ycombinator.com/item?id=13932591 https://news.ycombinator.com/item?id=13932591
Snappy 10y ago
The video in the blog post is all on Kubernetes as well, ans shows off terminal, deploy boards, and monitoring; all on Kubernetes. It doesn't go into detail, of course, but it's great if you just want to see it.

danial 10y ago

Congratulations on shipping 9.0. It's great to see a lot of improvements. Being able to reorder issues in the board is a welcome change. The subgroups is an interesting feature. I look forward to playing with it more. I am still waiting on the ability to view issues on a board across a group (or now, a subgroup). Since Gitlab projects are repo-centric, I have hard time tracking issues across many repositories in a single place. A board that is visible at a group-level would solve this problem. I believe this is a feature that's coming soon, though. I am looking forward to it.

microcolonel 10y ago
Not that this is a solution everywhere, but I'm always telling people that single-repo is the way to go for an integrated team. My rule is that if your business unit can reasonably control a codebase, and you have access to it, it should be in the same repo as your other codebases, full-stop. I've seen too many npm messes where people obsess over putting every button, dropdown, heading, and dumb image component in its own company-specific repo. Then they put the whole thing in a "UI kit" which realistically they will never reuse.
- bryanlarsen 10y ago
  Yup, I think Google & Facebook have this one right, a mono-repo is the way to go. But there are advantages to multi-repos, especially if you're trying to share with clients and/or open source. You can have your cake and eat it too: we use https://github.com/splitsh/lite https://github.com/splitsh/lite to update our micro-repos on every commit to our monorepo.
- victorwu 10y ago
  We originally built GitLab with that use case of a single repo in mind. Create a GitLab project, and you have a single repository for code. We know this is an important use case for many teams, because of it's straightforward, simple scenario. It's something that's important to us, even as we expand to other use cases of multi-repo teams (groups/subgroups housing of projects). Thanks for the comment.
10y ago

nik736 10y ago

As much as I love GitLab the UI/UX is still very weak compared to GitHub. And the sidebar change is something in the completely wrong direction. You should also really check out how it looks on a 4k screen.

GordonS 10y ago
Well, IMO the Github UI has been taking some steps backwards recently. If Gitlab keeps improving and Github worsening, they'll be at parity before too long
- MartinCron 10y ago
  That's not the way to reach parity!
- sytse 10y ago
  We certainly don't want to win in a race to the bottom. To get an idea what our UX team is working on please see their update from this Monday: Video https://www.youtube.com/watch?v=TMdw-plNfDQ https://www.youtube.com/watch?v=TMdw-plNfDQ Slides https://docs.google.com/presentation/d/1LM6wHxGVRwHwQvGJiXwF_HEsbP8OEfW3p6WbdNSkozU/edit?usp=sharing https://docs.google.com/presentation/d/1LM6wHxGVRwHwQvGJiXwF...
  - GordonS 10y ago
    I imagined you'd meet in the middle, rather than at the bottom! I like what you guys are doing - my comment was more meant as a well-natured jibe against the recent Github changes, which I'm really struggling to like (the black header a few weeks ago, and today the search results interface).
    - sytse 10y ago
      Ah, sorry for misreading it, I get caught up in the release excitement. <3
victorwu 10y ago

scott_karana 10y ago

For anybody else wondering where that gorgeous cover photo is from: Queenstown, New Zealand :-) https://about.gitlab.com/images/9_0/9_0-cover-image.jpeg https://about.gitlab.com/images/9_0/9_0-cover-image.jpeg https://www.google.ca/search?q=queenstown+new+zealand&source=lnms&tbm=isch https://www.google.ca/search?q=queenstown+new+zealand&source...

hmottestad 10y ago

Anyone know where that restaurant in the picture is? Looks amazing!

hmottestad 10y ago
Found it: https://www.omegarentalcars.com/support/blog/queenstown-luge-and-skyline-gondola/ https://www.omegarentalcars.com/support/blog/queenstown-luge...
timack 10y ago
http://www.skyline.co.nz/queenstown/restaurant/ http://www.skyline.co.nz/queenstown/restaurant/

apocalyptic0n3 10y ago

With the focus on performance, is there any chance we could get pagination on the deploy keys page? Our company is self hosting the CE version and we currently have 339 deployment keys. Every time we need to load the deployment keys page, it takes upwards of 20s. We could probably organize things differently and cut that down, but that would be a significant restructure and time investment for what would essentially be a band-aid. I (and others) have requested it before, but was told it was too low of a priority and it wouldn't be worked on.

connorshea 10y ago
I can't find an issue for this specifically, could you open one so we can get it tracked? https://gitlab.com/gitlab-org/gitlab-ce/issues https://gitlab.com/gitlab-org/gitlab-ce/issues
- apocalyptic0n3 10y ago
  The previous suggestions were done on the old suggestion site and I cannot find a link to that site anymore; it's been a while since I have personally brought it up but noticed all the mentions of performance improvements and, combined with our ever-growing list of keys, it felt like something to bring up again. @zegerjan made a ticket for it, but it's already been closed by Stan because it is being tracked by some general performance ticket. https://gitlab.com/gitlab-org/gitlab-ce/issues/29861 https://gitlab.com/gitlab-org/gitlab-ce/issues/29861
zegerjan 10y ago
I've opened an issue, as I couldn't find another. https://gitlab.com/gitlab-org/gitlab-ce/issues/29861 https://gitlab.com/gitlab-org/gitlab-ce/issues/29861 If we have it profiled we can give it the right priority.
flavor8 10y ago
Pagination on the list of commits in a PR would be awesome also. Oftentimes a week of work that's bundled in our develop->master RC merge will have more than 100 commits. Gitlab _only_ displays 100, and doesn't let you see the rest; since I like to skim down the commit messages to make release notes for the RC, this is pretty inconvenient.

tracker1 10y ago

I'm surprised, impressed, and frankly amused in that you can sign into gitlab.com with your github account.

jobvandervoort 10y ago
Glad to hear that. You can also import your projects directly (everything will be copied over). We don't see any reason for you not to do so. GitLab should be the easiest place to get started. If that means logging in with GitHub, we're happy to make that possible.
- Nadya 10y ago
  >You can also import your projects directly (everything will be copied over). I had forgotten about that, thanks for the reminder. I'll be moving all my stuff over this weekend once I curate out the things I don't actually use over on Github...
YCode 10y ago
They know their audience, I suppose. Anyway it makes importing projects easier.
hackerboos 10y ago
That's how I exported all my private Github projects and cancelled my pro account.

itwy 10y ago

The sidebar took a step backward in my opinion. I am missing the 'pin' option.

victorwu 10y ago
Thanks. Feel free to add feedback to the ongoing discussion here: https://gitlab.com/gitlab-org/gitlab-ce/issues/29835 https://gitlab.com/gitlab-org/gitlab-ce/issues/29835.
- buxtehude 10y ago
  Why did you remove the sidebar + pin again?? When you removed the sidebar last time - users of GitLab lobbied you hard to get that pin in there so they could keep that sidebar open at all times. These kind of changes make me feel like you're not understanding (respecting) your customers' needs (desires).
  - buxtehude 10y ago
    Sorry just to be clear - I really like GitLab - and I feel GitLab tries hard to make a great product for their users - and clearly they have a good understanding of the development community. It's just that I felt this issue had already been discussed and resolved - to be yet again undone. So just feeling frustrated we have to go through this again.

deleted 10y ago

[deleted]

machbio 10y ago

how is the CD in Gitlab complete without this issue being complete (https://gitlab.com/gitlab-org/gitlab-ce/issues/28497 https://gitlab.com/gitlab-org/gitlab-ce/issues/28497) - is there any alternative if i want to use "gitlab.com" for hosting my code ?

sytse 10y ago
Most of CD including deployments already works for private projects, it is only the auto deploy https://docs.gitlab.com/ee/ci/autodeploy/index.html https://docs.gitlab.com/ee/ci/autodeploy/index.html that doesn't work yet. We would all like to see auto deploy working with private projects and it is scheduled for 9.1 If you don't want to use GitLab.com to host your code you can install GitLab yourself or use the mirroring function in GitLab to deploy code hosted elsewhere.
- machbio 10y ago
  will just wait for "Gitlab.com" to get the functionality - is there any lag between Gitlab version upgrade and "Gitlab.com" using the upgraded Gitlab version ? Will wait it out for Gitlab 9.1 :) Thank you for the amazing work.
  - sytse 10y ago
    GitLab.com has RCs weeks before the official release. And you're welcome.

garou 10y ago

I am having problem with de CI/CD after update: ``` Running with gitlab-ci-multi-runner 9.0.0[...] Cloning repository... Cloning into '/builds/xxxxxxx'... warning: You appear to have cloned an empty repository. Checking out xxxxxxx as master... fatal: reference is not a tree: xxxxxx ```

garou 10y ago
I rebooted de entire machine and it is working now
- sytse 10y ago
  Thanks for reporting back, glad to hear it is working now.
tmaczukin 10y ago
For other who are seeing this issue: 'gitlab-ctl reconfigure && gitlab-ctl restart' should resolve this problem without a need to reboot the machine. The problem is tracked in https://gitlab.com/gitlab-org/gitlab-ce/issues/29855 https://gitlab.com/gitlab-org/gitlab-ce/issues/29855

jancsika 10y ago

I love and use Gitlab and am excited about the 9.0 performance improvements. On the other hand, I found it absurdly difficult to get feedback or action from Gitlab on an MR. There was an MR that fixed a critical problem in the virtualbox runner, and it sat there for about 5 months with no response to either the original submitter or my emails to gitlab/gitlab ci maintainers. About a month ago I finally decided to abuse your customer support addy to ask if somebody could force the maintainer to respond before the code rots. By that time the original submitter (who in comparison turned out to be easy to contact and collaborate with) was long gone. And another user had already announced a separate script they developed and maintained to work around the lack of merging this fix. I'm glad it finally got merged, but it was only after deciding to use my free time and treat the process as a kind of game to be beaten. But that's a one-off game I won't play again. Plus I doubt the original submitter, a Go developer, will be making another merge request. Anyhow, I made a list on the relevant issue tracker of the work it took to get the maintainer to eventually click the "merge" button: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_requests/313 https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_r...

ayufan 10y ago
Hi janciska, Thanks for writing that comment and making us aware of that case. I'm very sorry that it did that long to get reviewed and merged. The number of issues and merge requests that pass our hands is just crazy and sometimes it happens that some of them are oversight and not properly scheduled. Having people to be persistent, like you, makes them finally to be merged and be part of the product. Thank you for doing that! From our side, we will try our best to make this process to be more efficient. Kamil, CI/CD Lead at GitLab
- dataops 10y ago
  Kamil, Can GitLab have a hands-on demo at the upcoming DataOps Summit in Boston? https://www.dataopssummit.com/ https://www.dataopssummit.com/
- jancsika 10y ago
  Hi Kamil, Thanks for the reply. One point may not have been clear-- this isn't just a matter of a single bugfix being available to the userbase sooner rather than later. Rather, it is that multiple iterations through a development cycle were missed. From my rough recollection: 1. There was a problem setting up an OSX guest to work with virtualbox runner on OSX with passwords. We worked around this using pubkey-based auth between guest and host. 2. There was also a timeout issue mentioned on the tracker for which Sam found the relevant code and suggested (but did not create) a fix. 3. Sam seemed to think a snapshot-reuse approach was too complex and likely to hang or fail. I didn't agree and was trying to explore ways in which they could run reliably as it cut CI time in half for my use case. 4. For uploading artifacts, the OSX guest's gitlab-runner binary had the wrong name requiring the user to manually create a symlink with the correct name. (I think this is fixed in 9.0, but not sure since I still have the symlink there and it's still working.) At the time my CI builds (and probably Sam's) weren't working at all, so we both ate the cost of learning how the CI build system worked in order to debug it. If there had been feedback saying that his MR was the right (or wrong) approach I would have been happy to apply my knowledge gained at the time to the related problems mentioned above in order to debug and eventually fix them. But now that knowledge is gone. The cost for me to regain it outweighs the benefits of small improvements to what is atm a working if imperfect system. Edit: formatting

chetanahuja 10y ago

The new enhancements seem very promising. We've been using gitlab for our internal use for a while now. Having said that, every time a new gitlab release comes around, I always looks for updates in one area expectantly but mostly left unsatisfied. And that is, separation of the concept of Project from "one git repo" E.g., I want to manage a project that ties in issues from various different git repositories. It's pretty common. Almost no actual "project" in a real life business is limited to just one git repo. I want a system-wide wiki that collects knowledge about the entire operations. The idea that each wiki is tied to a particular git-repo is.. just... wrong. Heck, even the new search feature across projects somehow doesn't include wiki's. How did that decision get made? And so on and so forth.

jobvandervoort 10y ago
One of the high level goals I set for this year is scaling up to projects that consist of more than a single repository. That means CI that spans multiple projects [0], higher abstraction of issue management [1], formal relationships between issues [2] and more. Having a global wiki or higher level wiki should also be part of that [3], I think. [0]: https://gitlab.com/gitlab-org/gitlab-ee/issues/933 https://gitlab.com/gitlab-org/gitlab-ee/issues/933 [1]: https://gitlab.com/gitlab-org/gitlab-ee/issues/928 https://gitlab.com/gitlab-org/gitlab-ee/issues/928 [2]: https://gitlab.com/gitlab-org/gitlab-ce/issues/4058 https://gitlab.com/gitlab-org/gitlab-ce/issues/4058 [3]: https://gitlab.com/gitlab-org/gitlab-ce/issues/4037 https://gitlab.com/gitlab-org/gitlab-ce/issues/4037

jbk 10y ago

We've been using gitlab for most VideoLAN projects, and are moving towards it for all of them (including vlc and x264). A lot of things are great, and going in the right direction, but the issues tracker is really lacking. The lack of custom fields, that you find in all other bugtrackers except github, and the lack of dependent issues are really blocking us to move full to gitlab. And the biggest issue is that they're discussing to do it, but only in the non-open-source version, which we cannot use...

sytse 10y ago
Thanks for using GitLab. We have open sourced features based on your request before https://news.ycombinator.com/item?id=10931690 https://news.ycombinator.com/item?id=10931690 I can't promise anything regarding these features. Especially custom fields are a typical EE feature in our perspective. The dependent issues feature proposal https://gitlab.com/gitlab-org/gitlab-ce/issues/4058#note_24946893 https://gitlab.com/gitlab-org/gitlab-ce/issues/4058#note_249... is still on the CE tracker but I'm not sure what it's future is.
- jbk 10y ago
  Don't take me badly, Gitlab is the best thing around. We've tested many solutions... (too many) It's just that I really want to quit using trac, who is slow and not integrated with the rest of the infrastructure.
  - sytse 10y ago
    No worries, we love you too! Our Product Manager Victor Wu will email you to learn more.
deleted 10y ago
[deleted]
victorwu 10y ago
You are referring to this one right? https://gitlab.com/gitlab-org/gitlab-ee/issues/1906 https://gitlab.com/gitlab-org/gitlab-ee/issues/1906. Yes, it is currently marked as an EE feature. And Sid linked to the dependent issues feature below. Both of these features are not scheduled for development yet. We scope work out month to month, so we can't promise anything regarding those at this time. But we are discussing them as you see in the issues and considering how they would fit into our product as we recognize they are important features for many teams. For relations between issues, we are considering various designs, such as: https://gitlab.com/gitlab-org/gitlab-ee/issues/1941 https://gitlab.com/gitlab-org/gitlab-ee/issues/1941 and https://gitlab.com/gitlab-org/gitlab-ce/issues/29444 https://gitlab.com/gitlab-org/gitlab-ce/issues/29444.

imsodrunklol 10y ago

Jesus, they're killing it.

nik736 10y ago

You guys should look into your search functionality as it's not working for hours already :)

HankB99 10y ago

I wonder if this will provide a benefit in a resource constrained environment. I run the official Gitlab Docker/gitlab-ce container in a host with a J1900 processor and 4GB RAM and it is barely usable. Most pages timeout on the first load. At present it looks like it hasn't been updated since 2015.

dijit 10y ago
Currently running gitlab over docker on a dedicated 8 core system with 32G of ram, it routinely uses 9G of that for barely 30 users. (it's the only thing running on that physical host) So, keep that in mind.
- AlexCoventry 10y ago
  Which version of gitlab? Didn't they reduce memory demands in a recent release?
  - dijit 10y ago
    I keep it updated; it's now version 9 and still consuming 7G total used free shared buffers cached Mem: 31974 13984 17989 12 871 6047 -/+ buffers/cache: 7066 24907 Swap: 16367 The UI counts 10G for some reason. http://i.imgur.com/edAceQx.png http://i.imgur.com/edAceQx.png
    - brodock 10y ago
      Our omnibus package tries to use a % of your total memory for cache, so one way to reduce memory is fine tuning it. See for reference: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/attributes/default.rb#L373-380 https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/fil...

the_common_man 10y ago

Awesome release! What do people use to keep up to date with all the non-stop Gitlab releases? I used to use sandstorm but their port is very outdated by now (same goes for bitnami). I switched to cloudron and it has served me well but I am always on the look out for other solutions. On a side note, if you use the omnibus packages, are you a full time (or even part-time) sysadmin?

nsomaru 10y ago
Using omnibus (with backups), it's as simple as an 'aptitude upgrade' for us
- the_common_man 10y ago
  Have you just setup a cronjob for backups? And do you also test somehow that those backups work (or rely on gitlab doing the right thing?) Or maybe you use server snapshots? Also how how did you go about SSL?

teekert 10y ago

I like Gitlab, as an absolute noob I'm not really ready to make every mess of a program I use public (as Github requires). I fear that it can and will be used against me. I'm also such a small time user I think paying for Github is too much for my 3 > 200 lines projects. And so you end up at Gitlab. It works very well for me. If I want to, in the future, I can host it myself which is a nice thing. From this update I most like the dark-themed code view, yes I'm a simple man that is just learning how to code.

hpio 10y ago

Any idea how I can upgrade my docker installation on Kubernetes? At the moment in my Helm chart i have specified exat Gitlab and Postgresql version. Do i need to bump postgresql too when changing Gitlab?

maktouch 10y ago

Ah! Finally found the culprit :-) I run my fleet of runners in pre-emptible instances on GCP (they die after 24h). I forgot to pin the version in my startup script, so all it did was a simple apt-get install gitlab-ci-multi-runner. For some reason, version 9 of the gitlab runner cannot connect to our Gitlab (it fires a 404 on register). Anyways, look like 9 is a cool release, but we won't be upgrading until the sidebar comes back (did a little poll in the team and it 100% was in favour of the sidebar)

tmaczukin 10y ago
maktouch: Runner can't connect to GitLab because version 9.0 of Runner requires GitLab 9.0. We've noticed this in the release blog post: https://about.gitlab.com/2017/03/22/gitlab-9-0-released/#gitlab-runner-deprecation https://about.gitlab.com/2017/03/22/gitlab-9-0-released/#git... :) The reason is that in 9.0 we've prepared a new API for Runner requests (as part of new v4 version of API) and Runner 9.0 is using only this version. Version v1 of the CI API is still supported by Runner 1.10.X and 1.11.X. On GitLab's side it will be supported until August 2017 and until then we will also support Runner 1.11.X.