My uni uses a self-hosted GitLab for some projects, and they use a pretty recent version of it (at least 9.0). Of course, they now use the brand spanking new subgroup feature, which confuses drone a lot.
I do see all the projects of the subgroup in Drone. However, when I try to turn it on on my project, the switches turn on for ALL projects of the subgroup (all students in the course), but nothing happens : no webhook added, nothing in the left bar. Of course, reloading the drone page shows all switches to off.
At the same time, server-side logs are empty.
My theory would be that drone treats the subgroup name as the repository name, thus failing everything. This is because it expects the repository name in the form / (or /) with a single slash. This theory comes from the fact that, after toggling one (all) switch to on, I can click a settings cog. This cog leads me to the page to set options for the repository /, totally trashing the repo name part.
Oh and before anyone asks, yes, Drone works with my uni’s gitlab on repositories not using this subgroup thingy.
I would gladly contribute and try to fix this, but I lack the Go knowledge to do it . But if you need any more info, don’t hesitate.
This does not really help with the actual problem but IMHO it’s best to avoid
the subgroups feature Gitlab… For most projects it’s just a way to create
unnecessarily complicated nested repository structures instead of actually
solving problems.
Welp, maybe it’s a good thing, but simplifies management quite a lot in my uni’s case, since there’s a repo for each student attending the course.
They went from a simple group approach (<course name>_<year>/<student name>) but that required creating multiple groups.
Now, it’s much tidier in the form <course name>/<year>/<student name>.
The technical effort required to support sub-paths in drone is large. We would have to change the database, api, cli, web frontend – virtually every layer of the application would be impacted and require refactoring. Something like this could take months.
I will be very honest here …
I am not likely to implement this feature unless there is significant demand. I simply cannot justify the time, effort and cost involved. Lets assume it would take 3 months of my time to complete this task. The average salary for a senior engineer in SF (where I live) is approximately USD 140,000. We can therefore estimate the cost of this feature at USD 35,000.
I simply cannot financially justify this feature. I cannot afford to work on it. So the only way to push this feature forward, at this time, would be for someone to financially sponsor the feature and cover the cost of development.
. But if you need any more info, don’t hesitate.