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

61–70 of 87 posts

Re: GitLab 13.0

#61

Post by harrisonjackson »

apple4ever wrote: post #20

I really like GitLab, especially the Kubernetes integration. Its nice to see some Terraform integration as well. I do hope some of the security scanning goes to lower tiers, that can be very helpful. The biggest issue with GitLab I find is their stubbornness to have different prices for reporters vs developers[0][1]. It really makes no sense other than they just want more money (even though they are losing a bunch be…

Are you suggesting reporter users should be more or less expensive than developer users?

If you've got some users at a higher tier how are they going to interact with other users within a group that isn't on that tier?

Features recently moved down to silver from gold enabled us to leave jira which has been great. Epics + roadmaps

Re: GitLab 13.0

#62

Post by harrisonjackson »

ric2b wrote: post #57
boleary-gl wrote: post #45

Earlier quoted context omitted.

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.

+1 It is awesome to see a product manager, dev, and designer actively collaborating and commenting on a feature you're waiting for.

Re: GitLab 13.0

#63

Post by harrisonjackson »

traspler wrote: post #5

I really hope some of the the project management tools and scanning features will trickle down to the cheaper/free tiers some time. I can understand that not everything has to be free but the current feature split of project management and scanning features among the tiers feels a bit haphazard with some crucial things at the highest prices, making it hard to justify the in-between tiers and impossible to buy the hig…

Epics and roadmaps were moved down to less expensive tiers recently.

Relevant convos https://gitlab.com/groups/gitlab-org/-/epics/1887

Re: GitLab 13.0

#64

Post by mekster »

bebop wrote: post #31
subhrm wrote: post #15

Does gitlab offer a stripped down version with only vanila 'git' ?

You might want to look at gitea: https://gitea.io/en-us/ it is a pretty minimal git web application.

I wouldn't call it minimal. It's got enough for many workloads.

Re: GitLab 13.0

#65

Post by gnachman »

Since Gitlab is listening: users sometimes attach files to issues on my project and then regret it. There doesn’t seem to be any way to permanently delete such an upload. Sometimes these files have passwords or their employers’ secrets. I asked for help in the forums but got no response. Help?

Re: GitLab 13.0

#66

Post by zegerjan »

gnachman wrote: post #65

Since Gitlab is listening: users sometimes attach files to issues on my project and then regret it. There doesn’t seem to be any way to permanently delete such an upload. Sometimes these files have passwords or their employers’ secrets. I asked for help in the forums but got no response. Help?

The issue tracker I think is a better place for such a feature request.

Last time I worked on the attachment code, there wasn't a persistent database relationship for uploads and notes. Which would make this feature hard to implement, it would be a great feature though!

Re: GitLab 13.0

#67

Post by siscia »

folmar wrote: post #60
danudey wrote: post #51

Earlier quoted context omitted.

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

I have less than 20 environments to configure and it is already extremely messy in gitlab CI.

So messy that at the moment it is just a little toy and it will never actually work in production.

With 90? No there is no way you can create a reliable gitlab CI with so many environments.

Beside there are several bugs in gitlab CI and support is basically useless even for an organisation like ours where I believe we are one of their largest costumers. Our tickets (or at least the one I create) are simply ignored.

Re: GitLab 13.0

#68

Post by gravypod »

I love gitlab but I run into two issues constantly:

1. Gitlab CI with DinD kills the docker cache on every build. For a large monorepo this is a huge pain. Really needs to be addressed with some host volume mount of the docker daemon layer cache per concurrent job.

2. No say to specify CPU/disk/memory usage of a CI stage. I have a large number of builds that need ~512mb of ram per build and another build that needs 4GB of ram. Because of this I need to make sure every instance of the runner has exactly 4GB of ram available. This is a large waste of resources.

Gitlab is a fantastic product and I'm super happy for migrating multiple companies to it and that they keep innovating.

Re: GitLab 13.0

#69

Post by mcintyre1994 »

gravypod wrote: post #68

I love gitlab but I run into two issues constantly: 1. Gitlab CI with DinD kills the docker cache on every build. For a large monorepo this is a huge pain. Really needs to be addressed with some host volume mount of the docker daemon layer cache per concurrent job. 2. No say to specify CPU/disk/memory usage of a CI stage. I have a large number of builds that need ~512mb of ram per build and another build that needs 4…

On your second point, you can achieve this with tags. See here: https://docs.gitlab.com/ee/ci/yaml/#configuration-parameters and https://docs.gitlab.com/ee/ci/runners/#using-tags

On the runner side you can tell it which tags to accept, and on the .gitlab-ci.yml side you can tag your jobs.

We mainly use this to make most jobs run on AWS EC2 spot instances, but a few use on-demand instead. We also use it to give a couple of jobs a larger instance size.

Re: GitLab 13.0

#70

Post by gravypod »

mcintyre1994 wrote: post #69
gravypod wrote: post #68

I love gitlab but I run into two issues constantly: 1. Gitlab CI with DinD kills the docker cache on every build. For a large monorepo this is a huge pain. Really needs to be addressed with some host volume mount of the docker daemon layer cache per concurrent job. 2. No say to specify CPU/disk/memory usage of a CI stage. I have a large number of builds that need ~512mb of ram per build and another build that needs 4…

On your second point, you can achieve this with tags. See here: https://docs.gitlab.com/ee/ci/yaml/#configuration-parameters and https://docs.gitlab.com/ee/ci/runners/#using-tags On the runner side you can tell it which tags to accept, and on the .gitlab-ci.yml side you can tag your jobs. We mainly use this to make most jobs run on AWS EC2 spot instances, but a few use on-demand instead. We also use it to give a coup…

Can you do that within the same repo? I mainly work in a large monorepo.
Post reply on HN