I am sorry if it sounds like that, as my intention was just to provide some more data while waiting for the real case feedback. Hopefully, some users will provide their personal experiences.
I'd like to share more data on the UX front. There are two efforts underway to establish the experience baselines [1] as well as a common design system [2]
Hopefully these efforts allow us to look at our UX holistically, and to focus on making high-quality components that are used throughout the product.
Hi! GitLab employee here. While someone else from the community provides the feedback, I'd like to highlight what our support team can provide.
> GitLab offers a variety of support options for all customers and users on both paid and free tiers. You should be able to find help using the resources linked below, regardless of how you use GitLab.
Thanks for the feedback. We are working hard to improve performance and memory consumption of GitLab. We have two major projects underway, switching to Puma [1] as well as reducing the overall memory consumption of GitLab [2].
You can follow along on some of the progress we are making in each release post in the "Performance Improvements" section. For 12.2 you can see we had 58 MR's related to performance.
I wanted to share the following issues [1] & [2] with you and everyone else since the features you've mentioned are already being discussed. Feel free to leave your thoughts in there:
GitLab Community Advocate here. Thanks for the feedback, I am happy to hear that you like our product. Since you are still evaulating GitLab, please let me know if you need any assistance or help regarding other features.
GitLab review applications are a fantastic tool to enable stakeholders from Operations to QA to business owners to evaluate and approve application changes before production.
In GitLab 12.0, it's easy to provide visual feedback directly from the review app. It’s simple and streamlined, no toggling between different tabs and typing your feedback, helping to shorten review cycles and accelerate delivery. Documentation [1]
2. Project Dependency List
Projects typically include dozens of individual components, which can introduce vulnerabilities. Often, security and compliance teams need to be aware of the specific components included in a project. Documentation [2]
3. Limit access based on IP address
In GitLab 12.0, you can specifically prohibit traffic from outside IP addresses from accessing your GitLab data. Documentation [3]
You can find some more data about GitLab availability after the move to GCP here https://about.gitlab.com/2018/10/11/gitlab-com-stability-pos.... As we're trying to stay transparent as always, we'll definitely let everyone know if are going/thinking about the change.
Great news! I hope this will enhance the development of many great open source projects.
This has already been discussed at GitLab and it would be nice if something similar is implemented on other platforms as well. Here's the issue with more details https://gitlab.com/gitlab-org/gitlab-ce/issues/43468
Here's the overview of the three main improvements in this release:
1. Windows Container Executor is added to the GitLab Runner for using Docker containers on Windows. Previously, using the shell executor to orchestrate Docker commands was the primary approach for Windows, but with this update, you are now able to use Docker containers on Windows directly, in much the same way as if they were on Linux hosts. This opens up the door for more advanced kinds of pipeline orchestration and management for our users of Microsoft platforms. [1]
Included with this update is improved support for PowerShell throughout GitLab CI/CD, as well as new helper images for various versions of Windows containers. Please note that your own Windows runners can be used with GitLab.com, but are not currently available as part of the shared public fleet.
2. Multiple Assignees for Merge Requests - in GitLab 11.11, merge requests allow multiple assignees so all the people who are responsible for the change can be assigned to merge request. As with multiple assignees for issues, lists, filtering and notifications, and the API, all support multiple assignees for merge requests.
3. Caching Dependency Proxy for Container Registry. Lots of teams are using containers as part of their build pipelines, and having a caching proxy for frequently used upstream images/packages is a good way to speed up your pipelines. By keeping a copy of needed layers locally using the new caching proxy, you can improve execution performance for commonly used images in your environment.
For this initial iteration, the container proxy is only available for self-managed instances using the Puma (experimental) web server. Note that it's available only to Premium and Ultimate tiers.