Show runner group details in runner details page
Release notes
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, given that the runner is pre-created through the GitLab UI, the register command fails 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
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.
Intended users
User experience goal
Proposal
MVC feature | Design |
---|---|
Add a badge to indicate there is more than 1 runner in a group | #388854[default.png] |
Use the data from the most recently contacted system_id for runner groups in the table (status, IP address, last contact, etc.). |
#388854[default.png] |
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. |
#388854[details-expanded.png] |
Update the delete modal to say that X runners in this group will be deleted. | #388854[delete-runner.png] |
Further details
- The runners in the group may go stale often, so we've added automatic clean-up after it doesn't contact GitLab for 7 days.
- There could be up to 76 runners in a group (outlier). The mean is 4.
Permissions and Security
Documentation
Availability & Testing
Available Tier
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.
- We should also add instrumentation to the delete button for each runner in the group. This will help us understand if they need the ability to delete individual runners in the group or if they are relying on the auto delete.
- 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.