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.
86 karma · joined March 14, 2018
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.
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/
Here's the documented process for the relocating while working at GitLab: https://about.gitlab.com/handbook/people-operations/global-c...
Our Coffee Break Calls encourage team members to spend several hours a week socializing and building a relationship that's separate from work. Since working remotely can also lead to team members never meeting in person, we have a visiting grant [3] to cover transportation costs, and every nine months, the entire team gets together for the GitLab Contribute (ex Summit) [4]. The next Contribute happens in less than a 10 days and I can't wait for it!
[1] - https://about.gitlab.com/handbook/people-operations/group-co...
[2] - https://about.gitlab.com/handbook/communication/#company-cal...
[3] - https://about.gitlab.com/handbook/incentives/#visiting-grant
[4] - https://about.gitlab.com/company/culture/contribute/
I am sorry for the long list of links, just wanted to share as much as possible so people are aware of what the regular week at GitLab looks like :)
(I am working for GitLab btw)
1. Pipelines on the Operations Dashboard The Operations Dashboard allows users to have an overview of project information throughout the entire GitLab instance. You add individual projects, one by one, so it’s flexible to whichever specific projects are of interest. Also, the pipeline status information is added to the Operations Dashboard. This should help teams view the pipeline health of all the projects that they care about, together in a single interface. [1]
2. Pipelines for Merged Results When working in a feature (source) branch, it’s normal to have it diverge over time from the target branch if you aren’t rebasing frequently. This can result in a situation where both the source and target branch’s pipelines are green and there are no merge conflicts, but the combined output will result in a failed pipeline due to an incompatibility between the changes. By having your merge request pipeline automatically create a new ref that contains the combined merge result of the source and target branch, then running the pipeline against that ref, GitLab can better ensure that the combined result will be valid.Please note that if you are using merge request pipelines (in any capacity) and you use private GitLab runners that are version 11.8 or older, you will need to upgrade them to avoid running into the issue described in gitlab-ee#11122. Users of GitLab’s shared Runner fleet are not impacted. [2]
3. Suggest changes to multiple lines Collaborating on merge requests often involves spotting problems and suggesting a solution. In GitLab 11.6, we introduced support for suggesting a change to a single line. With 11.10, changes can now be suggested to multiple lines when leaving a comment on a merge request diff, and accepted with a single click, by any user with write permissions to the source branch. [3]
[1] - https://docs.gitlab.com/ee/user/operations_dashboard/
[2] - https://docs.gitlab.com/ee/ci/merge_request_pipelines/#pipel...
[3] - https://docs.gitlab.com/ee/user/discussions/#multi-line-sugg...
1. Pipelines on the Operations Dashboard The Operations Dashboard allows users to have an overview of project information throughout the entire GitLab instance. You add individual projects, one by one, so it’s flexible to whichever specific projects are of interest. Also, the pipeline status information is added to the Operations Dashboard. This should help teams view the pipeline health of all the projects that they care about, together in a single interface. [1]
2. Pipelines for Merged Results When working in a feature (source) branch, it’s normal to have it diverge over time from the target branch if you aren’t rebasing frequently. This can result in a situation where both the source and target branch’s pipelines are green and there are no merge conflicts, but the combined output will result in a failed pipeline due to an incompatibility between the changes. By having your merge request pipeline automatically create a new ref that contains the combined merge result of the source and target branch, then running the pipeline against that ref, GitLab can better ensure that the combined result will be valid.Please note that if you are using merge request pipelines (in any capacity) and you use private GitLab runners that are version 11.8 or older, you will need to upgrade them to avoid running into the issue described in gitlab-ee#11122. Users of GitLab’s shared Runner fleet are not impacted. [2]
3. Suggest changes to multiple lines Collaborating on merge requests often involves spotting problems and suggesting a solution. In GitLab 11.6, we introduced support for suggesting a change to a single line. With 11.10, changes can now be suggested to multiple lines when leaving a comment on a merge request diff, and accepted with a single click, by any user with write permissions to the source branch. [3]
[1] - https://docs.gitlab.com/ee/user/operations_dashboard/
[2] - https://docs.gitlab.com/ee/ci/merge_request_pipelines/#pipel...
[3] - https://docs.gitlab.com/ee/user/discussions/#multi-line-sugg...