A small thing I'd love to see - the ability to collapse all files in a merge request. Right now the only option is to expand all. We have a lot of generated test files and it nearly crashes the browser when they're all open. Right now I have to collapse each one individually, sometimes dozens of files.
There are some very nice features in this release:
1. VSCode MR viewing and CI autocomplete of env vars (and in next version adding comments) which finally means I can totally stop using clanky browser GUI for that but people that like it can.
2. PowerShell Core as shell runner on Linux
3. Suggestion in MR like on GH
4. Follow user like on GH
5. Automatic changelog via push tags
6. Recursive view of parent child pipelines (still some murky UI elements tho, like not being able to expand child on parent, something that worked previously). Unfortunately doesn't seem to be working with includes on trigger...
7. Reviewer follow up and viewed items. So far IMO, GH PR was much more pleasurable experience, maybe those 2 features will fix those problems for me - I am not sure if its just some quirk on my standalone or what but on GL I can't really understand what is going on after first review and provided fix. On GH PR, it simply hides changed lines that were previously reported as problematic but not on GL, several times it even didn't show commits that came afterwards. Rebasing also seem to mess the process up. Maybe I am just dumb.
I wish pipelines will get some filtering love, like viewing jobs by name and/or their status. Not really sure why this basic and very important stuff was never implemented. I sometimes have to scan several pages to find last instance of the job I am interested in (note that I use monorepo and each sub-service has its own standalone pipeline and parent triggers only specific ones based on code changes)
Another wish is option to select subset of all possible child pipelines when manually creating pipeline - now it triggers all of them.
Worth mentioning: we don't support generating changelogs when pushing tags. What we did add is an API that can be used to generate changelogs. This API takes a range of commits to use for the changelog. What we support here related to tags is automatically using the tag of the last release as the start of this range.
I've had some pains when creating base job definitions that I had to modify later (one of them is that after_script doesn't fail the job if it fails, for example) and I think I can solve almost all of them with this new feature.
Gitlab is one of the few programs I use where I'm actually looking forward to updates: things rarely break in updates and I have actual, useful improvements every month.
I have to use GitLab. But I really quite don’t get some features like:
Multiple published html pages per job. Seems not possible: You have to have a special job name “pages” and your build artifacts have to be in a special directory “public” in order for this job to work correctly.
Also collecting test coverage reports by grepping with a regex through your build stdout feels weird.
These 2 examples leave a weird feeling - a feeling that some easily applicable features are just bolted onto GitLab and the underlying architecture is not capable of incorporating these features an a better way (multiple html websites, specialized coverage report parsers).
Also extended/sharing pipelines between multiple teams without duplicating code or having stages “leaking into teams code” feels weird.
GitLab PM here. Great point on #2 about the regex. We have an open issue (https://gitlab.com/gitlab-org/gitlab/-/issues/21549) to parse more data from an uploaded coverage report and coverage percentage seems like a great first step so you don't have to mess around with the regex.
It would be fine if you could for example pick up cobertura reports or maybe some other coverage formats (Golang reports, Xcode coverage reports)
I know I can do this with all my Jenkins plug-ins. And maybe GitLab does not want to do all of this and people should use Sonarqube instead.
But it is hard to go to GitLab when I have seen the light with Jenkins.
Do you actually need CI? That's not a trick question; I don't use it on any of my personal projects. If so, GitLab is quite nice.
I absolutely love Gitea. If there's a nonzero chance I might ever want to rope in a friend on a personal project, Gitea makes it super easy to configure their permissions, let them open pull requests, etc.
If I know I'm never going to involve someone else, and I won't need CI, then bare-git repos are brilliant. I use this for things like maintaining a version history of files in /etc on my servers.
I started out using Gitlab for my personal repos, but have switched to using bare Git repos on a VPS for the last few years. If you won't be collaborating with anyone else, nothing beats being able to just write:
to note, gitolite provides a very simple addition to the 'simple git server over ssh' scenario without much hassle, might be worth looking into for this use case
using the multiuser support for automation sub-accounts ("service accounts") would be one thing; general 'separation of concerns' for higher security isolation (gitolite runs under a separate SSH account that can only run gitolite), has some hooks for offering read-only pull support using the git protocol pretty transparently.
but yes, i suppose pure single user it's not the hugest advantage.
This very release features a new mode [0] with reduced memory consumption. It probably still gets undercut by Gogs/Gitea, but it may be enough to run GitLab on a cheaper VPS tier than before.
I think this is aiming at 2GB Memory Tier. For majority of VPS that means they could move from $20/month to $10/month.
The problem is most popular Cloud/VPS ( DO, Linode, Vultr, UpCloud ) this tier gets you 1 vCPU only. Not sure how well this will work. Will have to test this.
Agreed; I have pretty limited time to spend on personal projects, so I try to minimize the amount of "infra" I have to maintain. I'm an activist about some things, but running my own git remotes and CI isn't one of them.
@cmckn - PM @ GitLab here - sorry to hear you had a poor experience with running our GitLab chart on k8s. We've been trying really hard to make this easier, but there is still some room to go especially on the documentation front: https://gitlab.com/groups/gitlab-org/-/epics/5273.
Gitea is a lot more than just a web UI. It's a whole multi-tenant platform if you need--it can act as an OAuth2 provider and drive SSO, login, etc. for all kinds of other apps or services. You could even have gitea used as a login/auth for a kubernetes cluster (with dex). It's like gitlab but way less documentation and slightly less polish.
Hooking it up to do SSO for other OAuth/OIDC apps is pretty similar. For something that doesn't do OAuth you could use vouch proxy in front of it and get SSO: https://github.com/vouch/vouch-proxy/issues/203
It's really slick and fun to throw gitea on a cheap VPS, then a few apps like drone CI, a k3s kubernetes cluster, etc. and have it all just interoperate and auth together seamlessly. I won't lie though it's an enormous amount of annoying and badly documented work to get it all together.
> bare-git is fine if you don't need any web presence.
cgit or gitweb can be nice additions to bare git for simple repository browsing without the full 'project managment' aspects that gitlab/gitea/redmine etc. add
I've tried to like Sourcehut, but I just can't. While I know some people love the "pull requests by email" workflow, it adds so much more friction for me that I don't even want to see what else the site has to offer.
Yes, hence the end to end encryption: https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingC... Once enabled as far as amazon is concerned your bucket is an entirely random bag of bits, they have no idea what's inside or how to access it. Even if compelled by a state government amazon can't give up your data in any usable form without your encryption keys.
I can't get over how easy it is with the Omnibus distribution. They obviously take great care in making sure it works. I keep ours up to date, so upgrades tend to be easy, but even going to new major releases (11->12, 12->13, etc.) have been just a "yum update" away and it all just works.
They've done this for quite a while too. When I took over managing our Gitlab instance it was 3 major versions behind. I just went back and followed their directions to get to certain minimal levels, then could do a major version update. Then do another incremental to another specific level, then do it again. It took a little while, but it worked perfectly.
I really appreciate the time and effort they put into making sure that the upgrade process is smooth.
Very welcome improvements in Code Review department. Really like the explicit Viewed checkbox (even though I noticed that the bolding in the sidebar with the file tree tried to solve the same problem) and really nice with the suggestions.
My two top wishlist leftover items in that regard are
1. Marking whether a comment requests changes or not. This is of course straight out of GitHub, but I think their flow better matches what I found to be happening a in a lot of changes. I see such states for a Code review of a MR: Changes approved, Reviewer requests changes, reviewer leaves feedback (like "nice implementation", "good refactor", "minor: maybe you can refactor this?"). The last one is the most blurry in the GitLab approach since the way we can solve it is by starting a comment thread that is not resolved and approving a MR at the same time but it feels clunky. Maybe they can take a page out of GitHub's book.
2. Personal slack notifications. I would love to have first-party support for the notification system around MR, MR Comments, Being assigned, pipeline failing that messages me privately on slack. Jira recently had a revamp in their slack app and all notification moved there and overall I welcomed these changes since the only other way it seems to be email which speaks for itself - limited interactivity and it's becoming less of a notification medium anyway. [1]
Hi! I'm the PM for Code Review at GitLab - thanks for all the feedback. The team really knocked it out of the park in 13.9 so it's great to see that being recognized.
> 1. Marking whether a comment requests changes or not. This is of course straight out of GitHub, but I think their flow better matches what I found to be happening a in a lot of changes. I see such states for a Code review of a MR: Changes approved, Reviewer requests changes, reviewer leaves feedback (like "nice implementation", "good refactor", "minor: maybe you can refactor this?"). The last one is the most blurry in the GitLab approach since the way we can solve it is by starting a comment thread that is not resolved and approving a MR at the same time but it feels clunky. Maybe they can take a page out of GitHub's book.
This is something we've been thinking about a lot and want to address. Right now our comments are pretty murky in that it's not clear what might be required. We'd like to add some kind of support here to make that clearer and you can see some issues in https://gitlab.com/groups/gitlab-org/-/epics/4349
We've also been thinking about this in the handoff part of the reviewer workflows (https://gitlab.com/groups/gitlab-org/-/epics/5074), as a way to signal what the expectation from the reviewer is once they've finished the review.
Thanks for the reply. Nice to see you guys are so appreciative of feedback. Thanks for linking the issue I will probably track it now since I was not able to find the nomenclature to find it before. I will probably ask our company account manager to point out that we would be interested in this since we do pay for your product in the end.
Whenever Code review surpasses the UX of GitHub, and i think they're close but just have different approaches to some stuff I think GH for Teams will have no advantage over GitLab. GitLab CI blows GitHub out of the water in my experience.
+1 especially on 2. I somehow can't set up the email notifications to work properly in my work group (just notify me when stuff happens in repos that I am an explicit maintainer/or just notify changes on MR I am involved in), so I can't even use the email -> slack integration. Weirdly the global GitLab notification works for my personal needs like following an MR on GitLab's repo.
Among the 299 community contributions in this release:
- GPU and smart scheduling support for GitLab Runner [1]
- The ability to follow other GitLab users [2]
- 1 line installer for the GitLab Kubernetes Agent [3]
- An activity filter on Vulnerability Reports [4]
1 - https://about.gitlab.com/releases/2021/02/22/gitlab-13-9-rel...
2 - https://about.gitlab.com/releases/2021/02/22/gitlab-13-9-rel...
3 - https://gitlab.com/gitlab-org/cluster-integration/gitlab-age...
4 - https://about.gitlab.com/releases/2021/02/22/gitlab-13-9-rel...
reply