Live data from Hacker News

GitLab 13.0

about.gitlab.com

71–80 of 87 posts

Re: GitLab 13.0

#71

Earlier quoted context omitted.

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.

Yep - I use a monorepo too. You just set tags on your runners, and tags on your CI jobs, and Gitlab’s scheduler will assign the jobs to correct runners for you. It’s worked perfectly for us.

Re: GitLab 13.0

#72
As said before it's frustrating that you can't browse source code or view replies to issues without javascript enabled. This is very basic functionality. I don't expect advanced stuff to work without javascript, but simple operations definitely should. Every other Git repository manager I know of, got this right. Just my two cents.

Re: GitLab 13.0

#73
post #11

It looks like it's now impossible to login to gitlab.com web interface via Tor. I only post it here because it was a recent sudden silent change that made gitlab.com unavailable to some, and there does not seem to be a response.

Can you try again - we are working on changes to our Cloudflare front end ( https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issu... ).

Works fine now, thanks! Sorry I made noise like this, I tried to find alternative channels of communication that presumably should work when someone cannot login via web for any reason, and failed.

Re: GitLab 13.0

#74

Earlier quoted context omitted.

You only need an SSH server for that.

You can combine ssh with multiple users to provide repo-level permissions (not branch level). You use standard linux permissions to enable deploy keys. You would also use git-shell on the read only ssh accounts for the deploy-keys. Without writing a new shell you wouldn't be able to do branch level protection.

Do you have a reference for such a barebones git setup anywhere? I’d love to get rid of Gitea currently in use for the team and replace it with simple Git + SSH. We don’t need branch level access control.

Last I checked, I gave up after try to set up keys for each user into a ‘git’ user in the VM running git. Any guidance here would be of great help.

Re: GitLab 13.0

#76

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

Reporters should absolutely be less. They are there to either view code or view & submit issues.

There are a lot of companies with 10 developers but 100 reporters. Why should those two groups of people cost the same? The interaction is easy - GitLab already works on the permissions with the different user types. And calculating cost is just as easy - how many reporters vs how many other types.

Re: GitLab 13.0

#77

Earlier quoted context omitted.

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

Reporters should absolutely be less. They are there to either view code or view & submit issues. There are a lot of companies with 10 developers but 100 reporters. Why should those two groups of people cost the same? The interaction is easy - GitLab already works on the permissions with the different user types. And calculating cost is just as easy - how many reporters vs how many other types.

110 users account is going to be one of the enterprise-y/gold/ultimate tier plans. They're going to get the enterprise-y price and subsidize the free and less-expensive tiers.

I would guess that most startups or small devshops using gitlab are going to have 5-6 devs to a maybe 1 reporter user.

Edit - I'm not disagreeing with you that a reporter user needs less features and in theory has a lower cost to gitlab. I think the target customer for the gold/ultimate tier that has reporter users won't blink at paying for it.

Re: GitLab 13.0

#78
Nothing against gitlab as I use and pushed for it in my company, but I feel it's heading towards Azure Devops(this might be entirely baseless). By that I mean it's geared more towards enterprise teams and business than startups looking to build stuff and deploy. I say this off the complexity of their UI, their feature set and what they seem to prioritize.

Re: GitLab 13.0

#79

Nothing against gitlab as I use and pushed for it in my company, but I feel it's heading towards Azure Devops(this might be entirely baseless). By that I mean it's geared more towards enterprise teams and business than startups looking to build stuff and deploy. I say this off the complexity of their UI, their feature set and what they seem to prioritize.

Most businesses prioritize what people pay them for (or they run out of money). Gitlab is accumulating enterprise features because enterprises are paying them for those features. Most places I've worked have used GitHub and it's good enough. Some also had Gitlab for "secret" stuff but if you trust GitHub with your main code then you already trust them with a lot so might as well just use them for all code hosting.

Re: GitLab 13.0

#80

Earlier quoted context omitted.

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.

Have you tried signing up with an @yandex.com email? The signup page just reloads with this message:

1 error prohibited this user from being saved: Email is not from an allowed domain.

You don't need to have a Yandex account for that. Just put in whatever@yandex.com as your email and you get the above message.

Post reply on HN