Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gitlab 13.9

about.gitlab.com

Post reply on HN
Print view View original

51–60 of 63 posts

Re: Gitlab 13.9

#51

Post by chrisdhal »

LeSaucy wrote: post #45

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.

Re: Gitlab 13.9

#52

Post by phikai »

sdfhbdf wrote: post #32

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 m…

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!

Re: Gitlab 13.9

#53

Post by cat199 »

kingosticks wrote: post #25
cat199 wrote: post #12

Earlier quoted context omitted.

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.

Re: Gitlab 13.9

#54

Post by tenaciousDaniel »

Normal_gaussian wrote: post #46
Normal_gaussian wrote: post #38

Earlier quoted context omitted.

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!

Re: Gitlab 13.9

#56

Post by raihansaputra »

sdfhbdf wrote: post #32

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 m…

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

Re: Gitlab 13.9

#57

Post by raihansaputra »

phikai wrote: post #52
sdfhbdf wrote: post #32

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 m…

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, Re…

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.

Re: Gitlab 13.9

#58

Post by john_cogs »

raihansaputra wrote: post #57
phikai wrote: post #52

Earlier quoted context omitted.

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, Re…

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.

Re: Gitlab 13.9

#59

Post by joshlambert »

cmckn wrote: post #40
Aeolun wrote: post #29

Earlier quoted context omitted.

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

Re: Gitlab 13.9

#60

Post by jamesh-gl »

weitzj wrote: post #39

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 feel…

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

Post reply on HN