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.

[1] - https://about.gitlab.com/handbook/engineering/ux/experience-...

[2] - https://about.gitlab.com/handbook/engineering/ux/pajamas-des...

> 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.

https://about.gitlab.com/support/

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.

[1] - https://docs.gitlab.com/omnibus/settings/puma.html

[2] - https://about.gitlab.com/handbook/engineering/development/en...

[3] - https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=...

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:

1 - A proposal to move MR Approvals to CE https://gitlab.com/gitlab-org/gitlab-ce/issues/42096

2 - Full history of edited comments https://gitlab.com/gitlab-org/gitlab-ee/issues/3706

1. Visual Reviews

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]

[1] - https://docs.gitlab.com/ee/ci/review_apps/index.html#visual-...

[2] - https://docs.gitlab.com/ee/user/application_security/depende...

[3] - https://docs.gitlab.com/ee/user/group/index.html#ip-access-r...

Google Cloud has resolved the issue as of 23:00 UTC yesterday. Any further information can be found on the issue at https://gitlab.com/gitlab-com/gl-infra/production/issues/862

GitLab is no longer seeing errors and Google Cloud has resolved the issue as of 23:00 UTC yesterday. Any further information can be found on the issue at https://gitlab.com/gitlab-com/gl-infra/production/issues/862

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

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.

Docs:

[1] - https://docs.gitlab.com/runner/executors/docker.html#using-w...

[2] - https://docs.gitlab.com/ee/user/project/merge_requests/#mult...

[3] - https://docs.gitlab.com/ee/user/group/dependency_proxy/

[1] - https://docs.gitlab.com/ee/user/project/pages/

[2] - https://about.gitlab.com/direction/release/pages/