8 ms·

Gitlab 13.9

91 points by bjoko 6y ago

john_cogs 6y ago
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-released/#gpu-and-smart-scheduling-support-for-gitlab-runner https://about.gitlab.com/releases/2021/02/22/gitlab-13-9-rel... 2 - https://about.gitlab.com/releases/2021/02/22/gitlab-13-9-released/#follow-user-activity https://about.gitlab.com/releases/2021/02/22/gitlab-13-9-rel... 3 - https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/merge_requests/281#note_507445139 https://gitlab.com/gitlab-org/cluster-integration/gitlab-age... 4 - https://about.gitlab.com/releases/2021/02/22/gitlab-13-9-released/#vulnerability-report-activity-filter https://about.gitlab.com/releases/2021/02/22/gitlab-13-9-rel...
- tenaciousDaniel 6y ago
  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.
  - john_cogs 6y ago
    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/reviewing_and_managing_merge_requests.html#file-by-file-diff-navigation https://docs.gitlab.com/ee/user/project/merge_requests/revie...
  - Normal_gaussian 6y ago
    Mark them linguist-generated in .gitattributes. GitLab will show them as changed but not show the diff.
    - Normal_gaussian 6y ago
      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.
      - tenaciousDaniel 6y ago
        This is an awesome tip though, thanks!
- wdb 6y ago
  Awesome, the issue from last Friday with npm really screwed up our own release.
ducktective 6y ago
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.
- richardwhiuk 6y ago
  IMHO, just use GitLab.com or GitHub.com's personal private repos options.
  - cmckn 6y ago
    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.
    - Aeolun 6y ago
      Running my own git remotes and infra is my personal project ;)
      - cmckn 6y ago
        Godspeed! I tried deploying gitlab on my k8s cluster at home and ran screaming after an hour or so haha
        Aeolun 6y ago
        Ah, yeah. I can’t be bothered with that either. I just run omnibus on a completely separate VM.
        joshlambert 6y ago
        @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 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 https://gitlab.com/gitlab-org/charts/gitlab/-/issues
akoncius 6y ago
nice work!
- sytse 6y ago
  thank you!
gjulianm 6y ago
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-tags 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.
majkinetor 6y ago
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.
- YorickPeterse 6y ago
  > 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.
sdfhbdf 6y ago
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 https://gitlab.com/gitlab-org/gitlab/-/issues/17958
- phikai 6y ago
  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 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 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!
weitzj 6y ago
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.
- jamesh-gl 6y ago
  GitLab PM here. Great point on #2 about the regex. We have an open issue (https://gitlab.com/gitlab-org/gitlab/-/issues/21549 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
  - weitzj 6y ago
    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.
    - jamesh-gl 6y ago
      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_coverage_visualization.html 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
pentagrama 6y ago
Is there a RSS feed for Gitlab (Community) releases? I found the releases page here https://gitlab.com/gitlab-org/gitlab-foss/-/releases https://gitlab.com/gitlab-org/gitlab-foss/-/releases But /rss or /atom (or .atom like GitHub does) do not have the feed.
- john_cogs 6y ago
  This is a feed for our monthly release posts: https://about.gitlab.com/releases.xml https://about.gitlab.com/releases.xml
  - pentagrama 6y ago
    Thank you!
LeSaucy 6y ago
I can't get over how easy it is to keep gitlab upgraded/up to date with docker.
- chrisdhal 6y ago
  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.
efiecho 6y ago
I'm looking forward to the release that will heavily reduce use of Javascript, at least on the frontend.
Lorin 6y ago
Wish the VSCode extension linked issues #s within code commentary like GitHub's extension does.

91 points by bjoko 6y ago

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-released/#gpu-and-smart-scheduling-support-for-gitlab-runner https://about.gitlab.com/releases/2021/02/22/gitlab-13-9-rel... 2 - https://about.gitlab.com/releases/2021/02/22/gitlab-13-9-released/#follow-user-activity https://about.gitlab.com/releases/2021/02/22/gitlab-13-9-rel... 3 - https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/merge_requests/281#note_507445139 https://gitlab.com/gitlab-org/cluster-integration/gitlab-age... 4 - https://about.gitlab.com/releases/2021/02/22/gitlab-13-9-released/#vulnerability-report-activity-filter https://about.gitlab.com/releases/2021/02/22/gitlab-13-9-rel...

tenaciousDaniel 6y ago
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.
- john_cogs 6y ago
  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/reviewing_and_managing_merge_requests.html#file-by-file-diff-navigation https://docs.gitlab.com/ee/user/project/merge_requests/revie...
- Normal_gaussian 6y ago
  Mark them linguist-generated in .gitattributes. GitLab will show them as changed but not show the diff.
  - Normal_gaussian 6y ago
    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.
    - tenaciousDaniel 6y ago
      This is an awesome tip though, thanks!
wdb 6y ago
Awesome, the issue from last Friday with npm really screwed up our own release.

ducktective 6y ago

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.

richardwhiuk 6y ago
IMHO, just use GitLab.com or GitHub.com's personal private repos options.
- cmckn 6y ago
  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.
  - Aeolun 6y ago
    Running my own git remotes and infra is my personal project ;)
    - cmckn 6y ago
      Godspeed! I tried deploying gitlab on my k8s cluster at home and ran screaming after an hour or so haha
      - Aeolun 6y ago
        Ah, yeah. I can’t be bothered with that either. I just run omnibus on a completely separate VM.
      - joshlambert 6y ago
        @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 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 https://gitlab.com/gitlab-org/charts/gitlab/-/issues

akoncius 6y ago

nice work!

sytse 6y ago
thank you!

gjulianm 6y ago

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

majkinetor 6y ago

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.

YorickPeterse 6y ago
> 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.

sdfhbdf 6y ago

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 https://gitlab.com/gitlab-org/gitlab/-/issues/17958

phikai 6y ago
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 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 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!

weitzj 6y ago

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.

jamesh-gl 6y ago
GitLab PM here. Great point on #2 about the regex. We have an open issue (https://gitlab.com/gitlab-org/gitlab/-/issues/21549 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
- weitzj 6y ago
  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.
  - jamesh-gl 6y ago
    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_coverage_visualization.html 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

pentagrama 6y ago

Is there a RSS feed for Gitlab (Community) releases? I found the releases page here https://gitlab.com/gitlab-org/gitlab-foss/-/releases https://gitlab.com/gitlab-org/gitlab-foss/-/releases But /rss or /atom (or .atom like GitHub does) do not have the feed.

john_cogs 6y ago
This is a feed for our monthly release posts: https://about.gitlab.com/releases.xml https://about.gitlab.com/releases.xml
- pentagrama 6y ago
  Thank you!

LeSaucy 6y ago

I can't get over how easy it is to keep gitlab upgraded/up to date with docker.

chrisdhal 6y ago
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.

efiecho 6y ago

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

Lorin 6y ago

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