Live data from Hacker News

GitLab 13.0

about.gitlab.com

81–87 of 87 posts

Re: GitLab 13.0

#81

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?

Hi! Thanks for reaching out! There's an open issue related to your question:https://gitlab.com/gitlab-org/gitlab/-/issues/16229

You can't delete attached files if some of them were uploaded by mistake - It's better to use the issue tracker for a feature request.

Re: GitLab 13.0

#82

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…

Hi the PM responsible for Terraform and Kubernetes integrations here. We would like to improve both our K8s and Tf support in the next months, and would be great to hear about your use-cases a bit more. What do you like or dislike wrt GitLab Kubernetes integration? Would you be open to a user interview?

Re: GitLab 13.0

#83
post #19

I was so happy when I saw the attention paid to deployment on ECS that I thought maybe they finally (years later) put some more attention into GCP[1], but it appears not. Hopefully in some time in the next few months! [1] https://gitlab.com/groups/gitlab-org/charts/-/epics/4

Hi Dimitri. We are in the process of deprecating the current GKE listing which Google will be replacing with a single click to deploy listing, currently targeted to go live before the end of June. Thanks for your interest and patience. For more details on other GCP plans see https://gitlab.com/groups/gitlab-com/-/epics/322 . Larissa Lane, Distribution Product Manager

Awesome! I'll look forward to that release!

Re: GitLab 13.0

#84
post #67
post #60

Earlier quoted context omitted.

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 on…

Oh wow! This is very much the kind of feedback we are looking for as we redesign our environments views. Can you share your issues here?

Re: GitLab 13.0

#85
post #67

Earlier quoted context omitted.

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 on…

Oh wow! This is very much the kind of feedback we are looking for as we redesign our environments views. Can you share your issues here?

Hi there,

this in our jenkins.

https://imgur.com/a/BkdgVHK

The matrix that you see is one of the most complex one, jobs that build the documentation are much simpler.

If you need more, please let me know.

Re: GitLab 13.0

#86

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.

It does get slightly more complicated since those are project level features. I don't know how many users exist that don't have Developer access on at least one repository.

Enforcement of that seems less than ideal. You would have to have GitLab check the number of Reporters and Developers any time someone gets Developer access to a repo. Which means that the repo owner gets the error when you run out of licenses, which is less than ideal. As opposed to a user limit, where presumably whatever team owns Gitlab gets the error when they add the user.

Re: GitLab 13.0

#87

Earlier quoted context omitted.

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.

I have tidied up my script and written some docs and put the result up here https://github.com/artumi-richard/ssh-git-hosting/
Post reply on HN