Gitlab 13.9 | Hacker News Reader

Gitlab 13.9

about.gitlab.com

91 pointsbjoko61 comments

GitLab team member here. One thing that stood out to me in this release is the strength of contributions from the wider GitLab community.

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...

Awesome!

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.

Have you tried enabling "Show one file at a time on merge request’s Changes tab"? That might help.

https://docs.gitlab.com/ee/user/project/merge_requests/revie...

Mark them linguist-generated in .gitattributes. GitLab will show them as changed but not show the diff.

I'd like to note that this is just a tip for the guy I replied to, not a dismissal of the request. GitLab still needs that button.

This is an awesome tip though, thanks!

Awesome, the issue from last Friday with npm really screwed up our own release.

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.

> Automatic changelog via push tags

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.

Of all the features, I am extremely happy about this one: reference tags in CI configuration https://docs.gitlab.com/ee/ci/yaml/README.html#reference-tag...

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.

-James H, GitLab Product Manager, Verify:Testing

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.

Cobertura is the first target report since it's the format that's supported by the Test Coverage Visualization feature (https://docs.gitlab.com/ee/user/project/merge_requests/test_...).

I'll make sure the other report types are on our list of future iterations as well.

Thanks!

-James H, GitLab Product Manager, Verify:Testing

Between Gitlab,Gitea and bare-git repos, which one should I use for personal (1-man) projects? Here are my thoughts:

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.

Here's my decision tree:

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:

   ssh $HOST git init --bare repo/foo
   git remote add origin $HOST:repo/foo

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

If it's just you using it, what additions does gitolite bring (genuine question)?

good point on individual users -

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.

Why would I tune for git init?

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.

[0] https://about.gitlab.com/releases/2021/02/22/gitlab-13-9-rel...

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.

Or as others have mentioned, just use Gitlab.com

IMHO, just use GitLab.com or GitHub.com's personal private repos options.

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.

Running my own git remotes and infra is my personal project ;)

Godspeed! I tried deploying gitlab on my k8s cluster at home and ran screaming after an hour or so haha

@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.

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

Ah, yeah. I can’t be bothered with that either. I just run omnibus on a completely separate VM.

As I see it:

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.

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.

> it can act as an OAuth2 provider and drive SSO, login, etc. for all kinds of other apps or services.

Can I get a link to documentation/discussion on that?

OAuth2 provider config: https://docs.gitea.io/en-us/oauth2-provider/

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.

> 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

Are there any nicer interfaces for gitweb? The basic functionality (just browsing a repo) is perfect but it's not the prettiest.

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

Another option might be SourceHut, although it's officially still in alpha. https://sourcehut.org/

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.

I'm leaving this here, no judgement, no further comment (ddevault is the CEO of sourcehut):

https://news.ycombinator.com/threads?id=ddevault

I don't have an answer for you but your question made me think; "why can't other gitlab alternatives use their gitlab runner?"

That shouldn't be hard to do, make a gitea that can use gitlab runners, right? It must be an open protocol.

interesting thought, isn't gitlab-ci-runner only pulling jobs to be executed and then pushes back logs? shouldn't be that hard to implement.

Exactly, it polls the Gitlab API for jobs, runs the jobs and sends back logs.

Any gitlab alternative could implement this and make each other re-invent a lot less code, while implementing Gitlab-like CI.

Gitlab is not terribly resource hungry? And not very latency sensitive either, so you can put it wherever you get the cheapest/best hosting.

It requires quite a lot of memory since it’s a massive rails app.

bare repo synced up to S3 is my vote, with end to end encryption enabled. Why give some third party access to your data if you don't need to?

S3 is a 3rd party for most people.

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 to keep gitlab upgraded/up to date with docker.

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]

[1]: https://gitlab.com/gitlab-org/gitlab/-/issues/17958

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.

Stay tuned!

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.

Is there a way to assign two people for a review? Currently I assign one and then switch when the first has finished their review.

Yes, you can have multiple reviewers.

+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.

Is there a RSS feed for Gitlab (Community) releases?

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.

This is a feed for our monthly release posts: https://about.gitlab.com/releases.xml

Thank you!

I'm looking forward to the release that will heavily reduce use of Javascript, at least on the frontend.

Wish the VSCode extension linked issues #s within code commentary like GitHub's extension does.

nice work!

thank you!

Reply on news.ycombinator.com