3 ms·

Our devops team loves Gitlab pipelines and pushed the decision through. If you're looking for a "killer feature" on Gitlab, pipelines is probably it. As a dev

by Merad 7y ago

Our devops team loves Gitlab pipelines and pushed the decision through. If you're looking for a "killer feature" on Gitlab, pipelines is probably it. As a developer I don't think there's a huge difference, especially since we don't use the issue tracking or wiki stuff (we're all in Jira/Confluence). My main complaint about Gitlab is that there are a lot of places where the UI is rough around the edges (lots of pages lack or have very minimal search/sort options) or has outright bad UX, as well as lacking some features that feel pretty basic to me. My main complaints about Gitlab at the moment: * Lack of search/sort, as mentioned above * We created teams in Gitlab to mirror our scrum teams... when you look at the team list in Gitlab, it shows everyone who has access to the team, which is our whole damned Gitlab account. The only way to find the actual team members is to scroll down the list looking for users with a delete icon by their name (which removes them from the team). * If you want to set a required number of approvals on merge requests, you also have to set the list of reviewers. I wanted to set two required approvers but let the devs assign who (normally their team)... no can do. * Poor support for making merge requests build the result the merge (instead of just the branch). We've tried setting it up a couple of times, but usually end up with MR's hung because Gitlab doesn't firing the right builds and end up having to turn it off. * If you have the server squash commits when closing a MR there's no way to set the commit message in advance; you have to type in the message just before you click the merge button. This wouldn't be an issue if it defaulted to using the MR description as the commit message, but it doesn't do that either...

emilycook 7y ago
Hi! GitLab employee, thank you for your feedback! I'm going to distribute it to the correct teams, but I wanted to respond to a few points: > when you look at the team list in Gitlab, it shows everyone who has access to the team This has been an ongoing issue for a while, but a fix is currently scheduled for 12.4: https://gitlab.com/gitlab-org/gitlab-foss/issues/44958 https://gitlab.com/gitlab-org/gitlab-foss/issues/44958 > server squashing commits You don't have to provide a custom squash message, and the default behavior will be either (a) taken from the first multi-line commit message in the merge, or (b) the merge request’s title if no multi-line commit message is found. Documentation: https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html#overview https://docs.gitlab.com/ee/user/project/merge_requests/squas... The original issue around this: https://gitlab.com/gitlab-org/gitlab-foss/issues/47149 https://gitlab.com/gitlab-org/gitlab-foss/issues/47149
- Merad 7y ago
  Thanks for taking the time to respond! Re squash commits: as a MR author what I want is the ability to set the commit message in advance (even if it's just a check box to say "use the MR title and description". Using a commit message is a sane default behavior, but not extremely helpful most of the time (IMO). If I'm going to rely on it for the message in my squashed commit I'm going to have to remember to check my branch history, and most of the time I'll probably have to do an interactive rebase to clean things up and ensure Gitlab grabs the correct commit message. It also negates the value of "squash on the server" - if I need to do an interactive rebase anyway, it only requires about 30 seconds extra to just do the squash myself.
  - emilycook 7y ago
    Ahh gotcha, you seem to have pretty much the same feedback as this comment: https://gitlab.com/gitlab-org/gitlab-foss/issues/47149#note_183101412 https://gitlab.com/gitlab-org/gitlab-foss/issues/47149#note_.... Commenting on this issue (and tagging @ntepluhina, one of the owners of the issue) with your feedback would be the best way for someone to see it! I can pass on the info too, but issue comments take precedence when we're prioritizing.

by Merad 7y ago

emilycook 7y ago

Hi! GitLab employee, thank you for your feedback! I'm going to distribute it to the correct teams, but I wanted to respond to a few points: > when you look at the team list in Gitlab, it shows everyone who has access to the team This has been an ongoing issue for a while, but a fix is currently scheduled for 12.4: https://gitlab.com/gitlab-org/gitlab-foss/issues/44958 https://gitlab.com/gitlab-org/gitlab-foss/issues/44958 > server squashing commits You don't have to provide a custom squash message, and the default behavior will be either (a) taken from the first multi-line commit message in the merge, or (b) the merge request’s title if no multi-line commit message is found. Documentation: https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html#overview https://docs.gitlab.com/ee/user/project/merge_requests/squas... The original issue around this: https://gitlab.com/gitlab-org/gitlab-foss/issues/47149 https://gitlab.com/gitlab-org/gitlab-foss/issues/47149

Merad 7y ago
Thanks for taking the time to respond! Re squash commits: as a MR author what I want is the ability to set the commit message in advance (even if it's just a check box to say "use the MR title and description". Using a commit message is a sane default behavior, but not extremely helpful most of the time (IMO). If I'm going to rely on it for the message in my squashed commit I'm going to have to remember to check my branch history, and most of the time I'll probably have to do an interactive rebase to clean things up and ensure Gitlab grabs the correct commit message. It also negates the value of "squash on the server" - if I need to do an interactive rebase anyway, it only requires about 30 seconds extra to just do the squash myself.
- emilycook 7y ago
  Ahh gotcha, you seem to have pretty much the same feedback as this comment: https://gitlab.com/gitlab-org/gitlab-foss/issues/47149#note_183101412 https://gitlab.com/gitlab-org/gitlab-foss/issues/47149#note_.... Commenting on this issue (and tagging @ntepluhina, one of the owners of the issue) with your feedback would be the best way for someone to see it! I can pass on the info too, but issue comments take precedence when we're prioritizing.