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.
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.
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
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.
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.
As Kamil already wrote, the number of notifications, issues and merge requests that we follow is enormous and sometimes something may be missed. I'm doing my best to have eye on everything but this is not always possible.
From my side I can only say that I'm very sorry that your work and work of all people engaged in this merge request was noticed so late. We're working on improving responsiveness in GitLab Runner project so hopefully we will avoid such delays in the future.
Tomasz,
developer at GitLab,
GitLab Runner project maintainer
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.
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...
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.
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 :/
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.
They've set a very high bar for GitLab because not only is GitHub a great repository and project UI, it is one of the best overall application interfaces out there.
It's difficult being compared with GitHub and bucketed with them from a UI perspective, but GitLab really are holding their own and seem up to it
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
Thank you for the feedback. The sidebar is indeed oft-discussed. And we don't claim we have all the right answers. We work hard every iteration to make the best decision, ship updates, and get feedback.
We are working hard to improve UX and navigation specifically at GitLab. Our UX team is focused on design and user research. Here's some work on the research end: https://gitlab.com/gitlab-org/ux-research/issues/3.
We also have a new research panel, which includes usability texting. Anyone is welcome to join to provide further feedback, which will significantly impact our product development.
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."
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.
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.
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.
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.
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.
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).
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.
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".
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.
```
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
```
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?
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)
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.
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?
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.
[+] [-] ploggingdev|9 years ago|reply
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.
[+] [-] sytse|9 years ago|reply
There are some controller timings that are red 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/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.
[+] [-] victorwu|9 years ago|reply
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.
[+] [-] victorwu|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] jancsika|9 years ago|reply
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_r...
[+] [-] tmaczukin|9 years ago|reply
As Kamil already wrote, the number of notifications, issues and merge requests that we follow is enormous and sometimes something may be missed. I'm doing my best to have eye on everything but this is not always possible.
From my side I can only say that I'm very sorry that your work and work of all people engaged in this merge request was noticed so late. We're working on improving responsiveness in GitLab Runner project so hopefully we will avoid such delays in the future.
Tomasz, developer at GitLab, GitLab Runner project maintainer
[+] [-] ayufan|9 years ago|reply
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
[+] [-] jbk|9 years ago|reply
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...
[+] [-] scott_karana|9 years ago|reply
https://about.gitlab.com/images/9_0/9_0-cover-image.jpeg
https://www.google.ca/search?q=queenstown+new+zealand&source...
[+] [-] danial|9 years ago|reply
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.
[+] [-] tomc1985|9 years ago|reply
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|9 years ago|reply
gitrepo.mycompany.com/product.git --> reverse proxy to git.mycompany.com/gitrepo/product.git
Should be straight forward in nginx
[+] [-] newsat13|9 years ago|reply
[+] [-] nik736|9 years ago|reply
[+] [-] nikcub|9 years ago|reply
It's difficult being compared with GitHub and bucketed with them from a UI perspective, but GitLab really are holding their own and seem up to it
[+] [-] GordonS|9 years ago|reply
[+] [-] victorwu|9 years ago|reply
This is the issue where we discussed the sidebar change. Feel free to see what contributed to the decision. https://gitlab.com/gitlab-org/gitlab-ce/issues/26200
This is the ongoing issue to discuss the change and any future iterations: https://gitlab.com/gitlab-org/gitlab-ce/issues/29835
We are working hard to improve UX and navigation specifically at GitLab. Our UX team is focused on design and user research. Here's some work on the research end: https://gitlab.com/gitlab-org/ux-research/issues/3.
[+] [-] victorwu|9 years ago|reply
https://about.gitlab.com/researchpanel/
[+] [-] kozikow|9 years ago|reply
[+] [-] sytse|9 years ago|reply
[+] [-] psankar|9 years ago|reply
[+] [-] connorshea|9 years ago|reply
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-p...
We also have some documentation on integrating with Kubernetes here: https://docs.gitlab.com/ee/user/project/integrations/kuberne...
[+] [-] Snappy|9 years ago|reply
[+] [-] teekert|9 years ago|reply
[+] [-] darkengine|9 years ago|reply
https://gitlab.com/gitlab-org/gitlab-omnibus-builder/issues/...
[+] [-] jobvandervoort|9 years ago|reply
Edit: more info in the issue you've posted.
[+] [-] apocalyptic0n3|9 years ago|reply
[+] [-] jhasse|9 years ago|reply
[+] [-] sytse|9 years ago|reply
[+] [-] jrobn|9 years ago|reply
[+] [-] lotyrin|9 years ago|reply
They are selling what one might call an "Omakase" experience for the whole SDLC. They call it "Idea to Production".
[+] [-] connorshea|9 years ago|reply
[+] [-] garou|9 years ago|reply
``` 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 ```
[+] [-] tmaczukin|9 years ago|reply
The problem is tracked in https://gitlab.com/gitlab-org/gitlab-ce/issues/29855
[+] [-] garou|9 years ago|reply
[+] [-] chetanahuja|9 years ago|reply
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.
[+] [-] maktouch|9 years ago|reply
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|9 years ago|reply
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.
[+] [-] imsodrunklol|9 years ago|reply
[+] [-] the_common_man|9 years ago|reply
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|9 years ago|reply
[+] [-] tracker1|9 years ago|reply
[+] [-] jobvandervoort|9 years ago|reply
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.
[+] [-] hackerboos|9 years ago|reply
[+] [-] YCode|9 years ago|reply
Anyway it makes importing projects easier.