Group runners should display all runners available to the Group

This is a spin-off of #19819 (closed) and #334686 (comment 620693062)

Release notes

"When users of the group runner UI visit their runners' page, they can see the runners that they administer, but this is not a full picture of the runners that are available to them. This change enables users to see all the runners they can use, that are made available to them at different levels: shared runners, and runner from parents groups, along with runners they administer."

In other words: Admins can manage all the runners under them, Devs can see all the runners available to them.

Problem to solve

There are two types of relationships between a "scope" (a project or group) with the runners they use:

1. The runners that are "owned" by a group:
   • all the runners in this group plus,
   • all the runners owned by subgroups.
2. The runners that can be used by jobs of a group:
   • which can be all runners in this group plus,
   • all the runners in descendant groups and projects plus,
   • all the group runners owned by ancestor groups plus,
   • all shared/instance runners.

When visiting the runners' admin page, both relationships could be represented by the UI to help users understand which are the resources they can manage and use.

See comment #337838 (comment 811564755) for more details

Intended users

• Delaney (Development Team Lead)
• Sasha (Software Developer)
• Devon (DevOps Engineer)
• Sidney (Systems Administrator)

User experience goal

The user should be able to see all the runners at their disposal as well as seeing why a given runner is a available to them.

Proposal

Design proposal

https://www.loom.com/share/99df714ea3af4d48902cd220dfd1c851

• Print all runners available to you to run jobs (runners in this group, all runners owned by ancestor groups, all instance runners). These would be listed in the All tab as well as the individual Instance, Group, and Project tabs, depending on what types of runners they are.
• Runners that you are not the owner of should have no actions available and no links to see details of those runners.
• 💡 I wanted to make it clear where these runners are coming from, so I proposed adding a switch to the filter bar that allows you to see only runners you manage vs all runners available to me. If we choose to go this route, I'll need to make sure we get the UI text reviewed.
• Note: Once we add owners, this will become MUCH more clear where those runners were registered.

Example of how this looks as a group owner:

all runners printed	instance runners available to me	only show me the runners I managed

Example of how this looks as an admin:

I can edit and click on all runners. I'd recommend we'd remove the toggle to show/hide runners available to me in this case as technically, it wouldn't do anything to the list.

Previous technical proposal (might need edits)

The feature can be done by adding a new filter parameter in the membership fields of the GraphQL

Such filter can be named ALL, ANCESTORS, or other... that are added to the groups listing !65673 (merged).

Further details

Permissions and Security

As users that are not administrators of a certain runner will be able to see it listed, some actions will not be available to them:

• They will not be able to edit, pause/activate, delete the runners that are in higher scopes, unless they have permissions over such higher scopes.

☝ As an additional benefit of this change, the Group Runners page can become available to all users that are members of the group -> They will see the list of runners without having administration capabilites.

Documentation

Availability & Testing

Available Tier

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

Links / references

Future iteration

Additionally, users should be able to select this option when visiting the Group Runner UI: