Warning when disabling shared runners in group

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) ?

Yeah to get it fixed would need an issue raising here: Issues · GitLab.org / GitLab · GitLab

The issue and discussion there would deem the best way forward either for removing that second sentence, or some other option as you mentioned. I haven’t personally used that feature on my self-managed instance so couldn’t comment much further on the functionality unless I started to use it. Like maybe not globally disabling all runners, but allowing checkboxes to choose which ones prior to disabling. I couldn’t imaging having to go back and individually enable each one - would be rather time-consuming.

1 Like