3 ms·
I run my own instance of Gitlab which basically means that I handle spam manually. It is a pain. Gitlab recently added a band-aid of a feature to require admin
by jancsika 6y ago
I run my own instance of Gitlab which basically means that I handle spam manually. It is a pain.
Gitlab recently added a band-aid of a feature to require admin approval for new sign-ups, which comes with its own obvious problems. But even the UI for that is clunky-- you have to click a button to reveal some options, find the option to delete the spammer, type (read: paste) the users handle as a failsafe, after which Gitlab takes you back to the main user view requiring you to click again on the unverified users tab.
Last time I talked about this problem someone from Gitlab claimed they were working on a feature to send an email with a simple link to click to approve/deny a user. That feature still has not shipped.
They did fix an unrelated catastrophic bug of keeping around artifacts on each branch even if you set an expiry. On a gitlab instance with even moderate development rate and moderate-sized artifacts this fills up the hard-disk with artifacts that the admin must manually delete (or manually create their own script to delete them, which is still a pain). However, their fix was to add a checkbox that defaults to the buggy behavior. Per project. So for every new user's project I have to manually tell them to turn this anti-feature off to keep from filling up the hard-drive with artifact spam. Or else write a damned script to go in and turn off this feature periodically.
The community edition of Gitlab feels a lot like the early Gnome 3 touch-screen stuff. Great in theory, but one quickly gets the sense that no one is dogfooding-- if they did these kinds of problems wouldn't exist.