New Group Runners view MVC

Release Notes

Group runners are now displayed in an expanded view, where you can more easily administer and manage the runners associated with the namespace. To view the new UI, on the left sidebar, select CI/CD. This view includes the number of online, offline, and stale runners associated with the group and sub-groups.

Note: This feature is being rolled out, see #336405 (closed)

Problem(s)

Currently, we have three levels at which Runner View and Management are available. Project Level, Group Level, and Instance Level.

• Currently the runners are placed in the settings menu within the CI/CD page. This makes it so that runners are only visible to masters of the project.
• Runners are a big deal to GitLab's CI/CD but are at the same time very secluded/not visible.
• Runners pages everywhere are a neglected piece of UI, which is used a lot by certain people. Having it be in the settings pages, makes it harder to reach/find.
• It's currently hard to gauge for people why their job is pending.. when all runners are already busy

Note: See #339258 (closed) for the issue for project runners.

Proposal

The proposal is to add a Runners page under CI/CD in the sidebar for each group and project. This page should show the available Runners for that particular project or group.

Ideally, the three levels should behave the same. Each level should show the runners under it the same way and if you have the right membership permission in the project and group you can manage them. The Admin level stays the same in that sense since anyone that has access to that is considered an Admin member.

In that sense, the existent Runner management page in Self-Hosted instances is a good baseline for what we are trying to achieve as Group management.

We can demote the Runner CI/CD settings to just do the work for disabling share runners or enabling specific runners and other things like that. Currently, the settings are also doing the work for management and viewing Runners which makes it difficult to build features where Runners are needed as first-class citizens.

Implementation Steps

• backend GraphQL API: Query "runners" in a given group !65673 (merged)
• backend GraphQL API: Field and mutation for group to use instance runners #336879 (closed) !67256 (merged)
• backend GraphQL API: Mutation to remove a runner from a group (and delete it if orphaned)
• backend Add read_group_runners permission !77253 (merged)
• backend Runner href using webUrl from the GraphQL API #333800 (closed)
• backend Add userPermissions to Runner #337438 (closed)
• frontend Add new empty page under Group -> CI/CD -> Runners (new feature flag) example URL: https://gitlab.com/groups/gitlab-org/-/runners !66376 (merged)
• frontend Add features for runner administration:
  • View and reset runner registration Token for the group. !66825 (merged)
  • List runners that can be used by the group
• frontend Roullout "Group -> CI/CD -> Runners" feature flag
• documentation To indicate that new page is available

Screens

New menu item for groups	Group runners

Disclaimer

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.