The goal of this page is to create, share and iterate on the Jobs to be Done (JTBD) and their corresponding job statements for the Runner group. Our goal is to utilize the JTBD framework to better understand our buyers' and users' needs.
Utilize JTBD and job statements to:
When using a CI/CD tool for the first time, I need to understand what software I need to install and configure to execute the pipeline jobs.
| Job statements | Maturity | Confidence | Source |
|---|---|---|---|
| When I have to address a specific CI build use case or CI platform administrative requirement, I want to configure the CI build software application to ensure that the CI/CD pipeline jobs can run successfully for the specified project types. |
|
Researched | Issue |
| When migrating from Jenkins, I want to understand how the new CI build software architecture is different from Jenkins agents, so that I can set up my infrastructure in the most optimal way. |
|
Issue | |
| When inspecting an existing job, I want to easily understand the role of an agent, so I can make decisions on its configuration. |
|
Issue |
When administering runners for a GitLab instance or group, I need to perform general administrative functions as quickly and efficiently as possible.
| Job statements | Maturity | Confidence | Source |
|---|---|---|---|
| When I am managing the execution of many CI jobs, I want an overall understanding of the job executors connected to my organization, so I can make effective decisions. |
|
Issue | |
| When a job executor is compromised, I want an easy way to secure it so that I can prevent vulnerabilities. |
|
Issue | |
| When administering runners for a GitLab instance or group, I want to be able to specify the automatic removal of what may be hundreds of runners that have not contacted the GitLab instances for a period of time that is configurable (example X days) so as to reduce the maintenance overhead of maintaining a large GitLab runner fleet. |
|
Researched | Issue |
| When helping a developer or team troubleshoot issues with a CI job that could be caused by a "failing" runner, I need to be able to determine, who registered the Runner,so that I can quickly troubleshoot and resolve the issue. |
|
Researched | Issue |
| When helping a developer or team troubleshoot issues with a CI job that could be caused by a "failing" runner, I need to be able to determine, which group the runner is associated with,so that I can quickly troubleshoot and resolve the issue. |
|
Researched | Issue |
| When administering runners for a GitLab instance or group, I need an easy way to determine how many runners are out of date by x versions so that I can help with compliance enforcement. |
|
Researched | Issue |
| When checking on CI jobs' performance in a GitLab instance, I want to see pending and running jobs so that I can quickly determine if there are performance issues with that runner and the underlying host system or platform. |
|
Researched | Issue |
| When administering runners for a GitLab instance or group, I need a direct way to validate that a team hosting their own runner is on the latest version or a version that I have validated and approved for our organization's use. |
|
Researched | Issue |
