Warning when disabling shared runners in group
Summary
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 (closed)).
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. We are not sure if it should be raised as a bug or a feature request. But we think that the second sentence should be replaced or removed since it is no longer accurate, and that another warning should be raised, this time for re-enabling shared runners recursively (which might erase specific configurations in subgroups/subprojects).
Steps to reproduce
- Create a group with many subgroups and projects in it.
- Disable shared runners at the top-level group.
- See warning modal.
Example Project
What is the current bug behavior?
The second sentence is not quite true anymore, since shared runners can now be re-enabled recursively using that same toggle button.
What is the expected correct behavior?
Only keep the first sentence.
Relevant logs and/or screenshots
Output of checks
Results of GitLab environment info
Expand for output related to GitLab environment info
(For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)
Results of GitLab application Check
Expand for output related to the GitLab application check
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true
)(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true
)(we will only investigate if the tests are passing)
Proposal
Remove the second sentence in the modal.