HN user
Junior Community Advocate at GitLab
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.
[1] https://about.gitlab.com/handbook/engineering/ux/experience-...
[2] https://about.gitlab.com/handbook/engineering/ux/pajamas-des...
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.
[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=...
This bug should be fixed with the release 12.2.4. More info at https://gitlab.com/gitlab-org/gitlab-ce/issues/66803
You can run GitLab on a local server https://about.gitlab.com/pricing/#self-managed
Sijbrandij is the correct one.
Thanks for the feedback.
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
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.
Here's the brief overview of the top 3 features:
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...
You can check https://about.gitlab.com/devops/ for more details about DevOps term. Also if you are wondering about GitLab DevOps lifecycle, here's the page explaining DevOps tooling https://about.gitlab.com/stages-devops-lifecycle/
Here's the blog post about it https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-...
That's true! Here's some more info about it https://about.gitlab.com/company/culture/all-remote/
That was related to the GCP issues, but there should be no more errors.
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
Yes, it was definitely related to GCP services.
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
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.
Totally agree! And it's already being discussed, here's the issue with more details about it https://gitlab.com/gitlab-org/gitlab-ce/issues/43468
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.
Docs:
[1] https://docs.gitlab.com/runner/executors/docker.html#using-w...
[2] https://docs.gitlab.com/ee/user/project/merge_requests/#mult...
Thanks for sharing the links. The GitLab Pages doc [1] and product vision [2] may be an interesting read as well.
Hi! Did you mean of https://news.ycombinator.com/item?id=18443561? Also, there's a blog post about why GitLab pays local rates https://about.gitlab.com/2019/02/28/why-we-pay-local-rates/.
My remote gig has several people who are pretty much digital nomads -- they move around often, travel even more often, and work from various states. We all get paid on the same scale (north-east coast based) so there's no issue; but, how would Gitlab handle this? Change their salary every time they log work from a new location?
Here's the documented process for the relocating while working at GitLab: https://about.gitlab.com/handbook/people-operations/global-c...
Here's a good read for everyone wondering why GitLab pays local rates https://about.gitlab.com/2019/02/28/why-we-pay-local-rates/.
That's right. GitLab has Group Conversations [1] every day at the time when West Coast and Europe overlap. The most-wanted hours in the company to organize meetings are dedicated to talking about different areas of the company and learning how they're performing. We also do a Company Call [2] every day, which comprises about five minutes of announcements and 25 minutes of people chatting.
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)
Overview of the three main improvements in this release:
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...
Overview of the three main improvements in this release:
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...
Glad to hear that you enjoy using GitLab! Here's a link if anyone wondered https://about.gitlab.com/product/pages/
Thanks for sharing the comparison!
Hey, is this the feature you'd like to have in GitLab https://gitlab.com/gitlab-org/gitlab-ce/issues/39380? It's already being evaluated, actually it's a WIP.
Here's the link if anyone wants more details https://docs.gitlab.com/ee/user/project/protected_branches.h.... It's available in both Core and Free tiers.