To give a bit of context, toggle button “Enable shared runners in group” (available in section Runners of group CI/CD settings) in GitLab versions prior to v16.2 used to deactivate shared runners recursively in all subgroups and subprojects. However, it did not enable shared runners recursively when toggled back (issue #299823).
We use GitLab version 16.4.1 (Community Edition) in a self-managed environment, and we were glad to see this “issue” resolved. In this version, with all subprojects and subgroups shared runners deactivated, enabling shared runners in parent group enables recursively shared runners in all subgroups and subprojects.
However, while testing this new feature, we observed a warning when disabling shared runners in a group:
It is a good thing to warn users before making that choice for a GitLab tree that might contain hundreds of groups and projects, each with their own needs and configurations. However, the second sentence is not quite true anymore, since shared runners can now be re-enabled recursively using that same toggle button.
That is the conclusion we came to within our team, when discussing these test results. What are the community’s thoughts on this warning ? Did anyone else observe it ? Should it be raised as an issue, to be fixed in a future update ? Should we ask for another warning, this time for re-enabling shared runners recursively (which might erase specific configurations in subgroups/subprojects) ?