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

GitLab 13.0

about.gitlab.com

Post reply on HN
Print view View original

51–60 of 87 posts

Re: GitLab 13.0

#51

Post by danudey »

kennyGitLab wrote: post #16
siscia wrote: post #9

The thing that is really missing in gitlab CI is the impossibility to define a matrix for builds. We have to do the same actions on different environments and it is very troublesome.

Agreed! That's why we are working on it this release - https://gitlab.com/gitlab-org/gitlab/-/issues/15356

I would love to see a situation where we could predefine a matrix and then toggle different products on or off.

For example, we have:

Models A, B, C, D Builds Debug, Release

Normally this would be

A Debug A Release B Debug B Release

And so on, and so on. In our case, where we have about 90 different models, it would be extremely useful to be able to configure, via a GUI of some kind, which of those intersections we want, rather than rebuilding the entire set for a configuration option which only affects one or two models.

At this point, the only option available to us is the Jenkins Matrix Build Plugin, which is awful in a few fairly frustrating ways, but is also the only thing that does what we want.

Examples: configuring an SCM in a matrix build job results in one svn checkout for the matrix build job and one checkout each for the cartesian product, and then, since we have a separate child job for doing builds, one checkout each for the child jobs. We don't want the matrix job to do any checkout, but if you configure it with a Git or SVN URL then it will do it regardless.

Re: GitLab 13.0

#53

Post by sytse »

yuters wrote: post #48
boleary-gl wrote: post #24

Earlier quoted context omitted.

It is! We're super excited about it. We've been running it on GitLab.com for some time now, and it's been great to see.

According to the blog post, the labels are saying that this isn't available on any versions (free, bronze, silver, gold) of gitlab.com?

We didn't mark it as a feature of GitLab.com since the company decides if it is used, we also pay for the hosting (memory) cost, and there should be no end-user difference between Puma and Unicorn. But I agree that there is an argument for marking it as available there since all of GitLab.com runs on it.

Re: GitLab 13.0

#54

Post by orf »

oweiler wrote: post #28
majkinetor wrote: post #26

Exporting environment variables via artifacts sounds like a strange decision, but I guess its one way to do it. After years of waiting for jobs to communicate other then relying on file artifacts this is somewhat disappointing. I would like to see parent/child pipelines recive some love as currently it does work but quirks are all around. For example, its not easy (or sometimes even possible) to pass pipeline variabl…

The caching is so broken it's barely usable. You can't easily exclude files. The cache can't be updated incrementally. It's often slower than downloading all dependencies on every build.

The caching is not broken and it's completely usable. It sounds like you've got a weird specific use case that doesn't benefit from a general solution.

Re: GitLab 13.0

#55

Post by throwaway483284 »

joshlambert wrote: post #43
throwaway483284 wrote: post #42

I am running Gitlab in Docker (using official images), how would you go with upgrading from version 12.10 without losing any data? I am using volumes for Gitlab data.

Please read through the upgrade notes for 13.0 as there are some important changes like PG11 being a minimum requirement. As for the actual upgrade, you should be able to follow the standard process outlined here since you are persisting your data outside the container: https://docs.gitlab.com/omnibus/docker/#update

Updated without any issues, thanks.

Re: GitLab 13.0

#56

Post by morelisp »

orf wrote: post #54
oweiler wrote: post #28

Earlier quoted context omitted.

The caching is so broken it's barely usable. You can't easily exclude files. The cache can't be updated incrementally. It's often slower than downloading all dependencies on every build.

The caching is not broken and it's completely usable. It sounds like you've got a weird specific use case that doesn't benefit from a general solution.

The caching has worked great for me for Java / JVM languages, and decently for Go (but a proxy is usually better).

It is unusable for NPM or composer, or the version of yarn we use (maybe newer ones too but I know they were trying to improve their internal cache a while back). Anything with a ton of small files or entire git histories. It’s awful, and it’s not weird or specific.

Re: GitLab 13.0

#57

Post by ric2b »

boleary-gl wrote: post #45
candiddevmike wrote: post #36

The Terraform bits are incredible, GitLab has almost made Terraform Enterprise irrelevant (aside from sentinel, for now). Will we see Vault management soon too?

GitLab Developer Evangelist here. Short answer: yes. Long answer: Also yes, but with a link to the relevant epic: https://gitlab.com/groups/gitlab-org/-/epics/2875

I love this GitLab's transparency.

Most companies simply ignore questions like these because letting users know the roadmap is somehow scary.

Re: GitLab 13.0

#58

Post by boleary-gl »

boleary-gl wrote: post #47
TekMol wrote: post #27

Earlier quoted context omitted.

Hi! Yandex. Am I really the first to tell you? Yandex has a 30% market share in Russia.

No idea! But I'm going to find out :)

So we don’t think we’re explicitly blocking that and have users with that domain.

Could you DM / email me the details and a screen shot? I’ll try and help as best I can.

Re: GitLab 13.0

#59

Post by Already__Taken »

latch wrote: post #35
oweiler wrote: post #28

Earlier quoted context omitted.

The caching is so broken it's barely usable. You can't easily exclude files. The cache can't be updated incrementally. It's often slower than downloading all dependencies on every build.

Instead of caching node_modules, cache node_modules.tar.szt Then wrap your job in a untar/tar: tar --use-compress-program zstd -xf node_modules.tar.zst || true YOUR NORMAL JOB tar --use-compress-program zstd -cf node_modules.tar.zst node_modules (and you can delete things you don't need if you want)

That's weird won't these all be docker layers somewhere in the guts? So it's already compressed.

Re: GitLab 13.0

#60

Post by folmar »

danudey wrote: post #51
kennyGitLab wrote: post #16

Earlier quoted context omitted.

Agreed! That's why we are working on it this release - https://gitlab.com/gitlab-org/gitlab/-/issues/15356

I would love to see a situation where we could predefine a matrix and then toggle different products on or off. For example, we have: Models A, B, C, D Builds Debug, Release Normally this would be A Debug A Release B Debug B Release And so on, and so on. In our case, where we have about 90 different models, it would be extremely useful to be able to configure, via a GUI of some kind, which of those intersections we w…

You can get quite close with includes and yaml anchors
Post reply on HN