Among the 299 community contributions in this release:
- GPU and smart scheduling support for GitLab Runner 
- The ability to follow other GitLab users 
- 1 line installer for the GitLab Kubernetes Agent 
- An activity filter on Vulnerability Reports 
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...
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.
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.
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.
-James H, GitLab Product Manager, Verify:Testing
I'll make sure the other report types are on our list of future iterations as well.
Gitlab is resource-hungry but provides CI solutions and is kind of a setup-once-then-forget solution.
Gitea is light weight but for any additional functionality third-party utilities are needed.
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.
ssh $HOST git init --bare repo/foo
git remote add origin $HOST:repo/foo
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.
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.
Or as others have mentioned, just use Gitlab.com
I'd love to hear what you had trouble with, so we can continue to improve. If you'd like, can also open an issue here: https://gitlab.com/gitlab-org/charts/gitlab/-/issues
GitLab has CI and a whole host of other features (artifact repositories, pages, ...)
Gittea is a nice WebUI for viewing source files with simple issue and patch management.
bare-git is fine if you don't need any web presence.
Can I get a link to documentation/discussion on that?
For dex (k8s auth), specifically: https://dexidp.io/docs/connectors/gitea/
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.
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
Edit: this looks like what I mean, just so happens to be github style but that's not a requirement! https://github.com/kogakure/gitweb-theme
That shouldn't be hard to do, make a gitea that can use gitlab runners, right? It must be an open protocol.
Any gitlab alternative could implement this and make each other re-invent a lot less code, while implementing Gitlab-like CI.
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.
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. 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.
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.
I found the releases page here https://gitlab.com/gitlab-org/gitlab-foss/-/releases
But /rss or /atom (or .atom like GitHub does) do not have the feed.