New runner details page to support groups of runners
Release notes
With the new runner registration method, runners can now be in groups if they share the same authentication token, which means they have the same configuration. Runner groups will be added to the list of runners to make it clear that they have the same configuration, and runner group details will be accessible. This will help reduce the number of duplicate runners on the Runners
pages, allowing users to manage fewer runners at once.
Problem to solve
Today, we use registration tokens to register a runner for protected branches, and for any tags. In this case, the registration token has permission to do everything. Effectively, someone taking a possession of registration token could steal secrets or source code. As part of New Runner creation workflow in Admin Area > Ru... (#383139 - closed), a user can register runners using the same authentication token, but cannot make changes to the configuration unless they are the creator. Admins still need the most critical data visible so they can manage the runners appropriately and fix anything that's going on. The most important detail is the status of the runners in that group.
Additional details
Since the runner is pre-created through the GitLab UI, the register command will fail if provided with arguments that are exposed in the runner creation form. Some examples are --tag-list (tags), --run-untagged (run untagged jobs), --locked (lock a runner), or --access-level as these are sensitive parameters that should be decided at creation time by an administrator/owner. This means that there can be many runners registered with the same authentication token, but they all will be configured (tags & other arguments listed above) the same. Each runner in the group will have unique data associated with it:
-
platform
- helps the user learn more about the environment of the runner -
architecture
- helps the user learn more about the environment of the runner -
executor
- helps the user learn more about the environment of the runner -
IP address
- helps the user figure out which physical machine this runner is running on -
created date
- helps the user determine when this particular machine was first seen -
last contacted date
- helps the user determine if that machine is alive -
version
andupdate status
- helps the user learn which version the runner is running -
jobs
- helps the user debug any job < > runner failures
Intended users
User experience goal
The user should be able to see details of a runner group in the UI.
Proposal
- Add a new details page for runner groups that lists all data about the config first and adds an accordion with a new
Runners
value that includes runner manager-specific data (system_id
, status, IP address, etc.). This should be expanded by default. - Add tracking to the
Show details
/Hide details
accordion. 🎨 Designs in design management✨ Figma file
Implementation plan
-
Add runners count !121267 (merged) -
Add basic table with system ID and last contact !121400 (merged) -
Add more information: IP address, version, executorName, architecturePlatform !121829 (merged) -
Add upgrade status icon !122474 (merged) -
Add status badges
Further details
Permissions and Security
Documentation
Availability & Testing
Available Tier
- Free
Feature Usage Metrics
- We should add instrumentation to the accordion in the runner details page to see how often users are trying to look into runner group details (this is added in the proposal).
- We can monitor the number of visits to the detail pages and see if it increases after this feature is added.
What does success look like, and how can we measure that?
- We should no longer see a bunch of runners clogging up the UI for Kubernetes purposes - gitlab-runner#3692.
- Admins should be able to get more information on a problem with a runner by drilling into details.
What is the type of buyer?
Is this a cross-stage feature?
What is the competitive advantage or differentiation for this feature?
Links / references
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.