[HN Gopher] Gitlab 13.9
       ___________________________________________________________________
        
       Gitlab 13.9
        
       Author : bjoko
       Score  : 50 points
       Date   : 2021-02-22 19:31 UTC (3 hours ago)
        
 (HTM) web link (about.gitlab.com)
 (TXT) w3m dump (about.gitlab.com)
        
       | john_cogs wrote:
       | 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...
        
         | tenaciousDaniel wrote:
         | 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.
        
       | akoncius wrote:
       | nice work!
        
         | sytse wrote:
         | thank you!
        
       | majkinetor wrote:
       | 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 wrote:
         | > 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.
        
       | ducktective wrote:
       | 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.
        
         | MaxBarraclough wrote:
         | Another option might be SourceHut, although it's officially
         | still in alpha. https://sourcehut.org/
        
           | kstrauser wrote:
           | 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.
        
           | blueflow wrote:
           | I'm leaving this here, no judgement, no further comment
           | (ddevault is the CEO of sourcehut):
           | 
           | https://news.ycombinator.com/threads?id=ddevault
        
         | kstrauser wrote:
         | 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.
        
         | richardwhiuk wrote:
         | IMHO, just use GitLab.com or GitHub.com's personal private
         | repos options.
        
           | cmckn wrote:
           | 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 wrote:
             | Running my own git remotes and infra _is_ my personal
             | project ;)
        
         | INTPenis wrote:
         | 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.
        
         | kevincox wrote:
         | 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.
        
           | qbasic_forever wrote:
           | 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.
        
             | bsder wrote:
             | > 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?
        
               | qbasic_forever wrote:
               | 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.
        
           | cat199 wrote:
           | > 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
        
             | kingosticks wrote:
             | 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
        
         | hs86 wrote:
         | 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...
        
         | kipari wrote:
         | 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
        
           | cat199 wrote:
           | 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
        
             | kingosticks wrote:
             | If it's just you using it, what additions does gitolite
             | bring (genuine question)?
        
           | jayd16 wrote:
           | Why would I tune for git init?
        
           | [deleted]
        
         | Aeolun wrote:
         | Gitlab is not terribly resource hungry? And not very latency
         | sensitive either, so you can put it wherever you get the
         | cheapest/best hosting.
        
         | qbasic_forever wrote:
         | 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?
        
           | xtracto wrote:
           | S3 is a 3rd party for most people.
        
             | qbasic_forever wrote:
             | Yes, hence the end to end encryption: https://docs.aws.amaz
             | on.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.
        
       | sdfhbdf wrote:
       | 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
        
       | gjulianm wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2021-02-22 23:01 UTC)