[HN Gopher] Faster Gitlab CI/CD pipelines
       ___________________________________________________________________
        
       Faster Gitlab CI/CD pipelines
        
       Author : iduoad
       Score  : 16 points
       Date   : 2021-12-09 21:11 UTC (1 hours ago)
        
 (HTM) web link (blog.nimbleways.com)
 (TXT) w3m dump (blog.nimbleways.com)
        
       | boleary-gl wrote:
       | GitLab team member here - thanks for this write up! Great to see
       | your thought process throughout.
        
         | john_cogs wrote:
         | +1 - thanks for sharing!
        
       | aetherspawn wrote:
       | It's hard to know whether to cache CI or not.
       | 
       | On one hand, without the cache builds can be very slow.
       | 
       | But on the other hand, you'll see in a lot of projects random
       | commits like "blow away corrupted cache", which makes you wonder
       | whether building the cache from scratch is an important step of
       | reproducible builds. I personally rather let the builds run
       | longer and be absolutely certain.
       | 
       | Maybe there's a good middle ground for dev commits vs final merge
       | commits, but unfortunately there's no machinery in ie GitHub to
       | specify a commit as final before merge.
        
         | dannyz wrote:
         | I agree, tracking down a failed CI build that ends up being a
         | cache problem is much more frustrating to me than waiting a
         | little longer for the build.
        
         | whateveracct wrote:
         | NixOS Gitlab Runners are quite nice in this regard. Caching for
         | "free" (cost of admission: learning Nix)
        
         | exdsq wrote:
         | It's not perfect but you could have a word in the commit
         | message that the pipeline looks for and acts upon, so default
         | using cache but let you not use it with "NO-CACHE: <message>"
        
         | IanCal wrote:
         | Would a two step process work there? A staging branch which is
         | always built from scratch and which is then merged into main?
         | Or main & then tagged commits for releases?
        
         | whazor wrote:
         | I remember there is an empty cache button in the UI of Gitlab.
        
       | stabbles wrote:
       | My impression is that Github actions are more convenient, as jobs
       | are split into steps, and steps share the filesystem state
        
         | iechoz6H wrote:
         | Not so convenient if your code is on GitLab.
        
       ___________________________________________________________________
       (page generated 2021-12-09 23:00 UTC)