Include information about GitLab.com Runner machine types for a pool of shared runners

Release notes

Problem to solve

Runners at the project level (settings/ci-cd) do not indicate anything about Runner SaaS build machine compute types. Therefore, it is difficult for any user to figure out which types of Runners are available, the compute and memory resources available in that runner, how to use an identified Runner in their CI jobs, and the applied cost factor which impacts minutes used and their cost.

User story

As a GitLab SaaS CI user I want to quickly identify the available Runner machine types on GitLab SaaS for running my CI job.

JTBD

When I am troubleshooting CI jobs, I want to quickly know if the problem connects with the job execution agent, so I can resolve the problem and continue working.

Intended users

• Sasha (Software Developer)

User experience goal

The user should be able to identify the machine type that their shared runners at their organization are using.

Proposal

TBD.

Must incorporate the following machine types:

Runner Type	Shared Runner name	Tags	Run untagged jobs
Linux - Container Builds	1-green.shared.runners-manager.gitlab.com/default	docker;east-c;gce;git-annex;linux;mongo;mysql;postgres;ruby;shared	Yes
Linux - Container Builds	2-green.shared.runners-manager.gitlab.com/default	docker;east-c;gce;git-annex;linux;mongo;mysql;postgres;ruby;shared	Yes
Linux - Container Builds	3-green.shared.runners-manager.gitlab.com/default	docker;east-c;gce;git-annex;linux;mongo;mysql;postgres;ruby;shared	Yes
Linux - Container Builds	4-green.shared.runners-manager.gitlab.com/default	docker;east-c;gce;git-annex;linux;mongo;mysql;postgres;ruby;shared	Yes
Linux - Container Builds	5-green.shared.runners-manager.gitlab.com/default	docker;east-c;gce;git-annex;linux;mongo;mysql;postgres;ruby;shared	Yes
Linux - Container Builds	1-blue.shared.runners-manager.gitlab.com/default	docker;east-c;gce;git-annex;linux;mongo;mysql;postgres;ruby;shared	Yes
Linux - Container Builds	2-blue.shared.runners-manager.gitlab.com/default	docker;east-c;gce;git-annex;linux;mongo;mysql;postgres;ruby;shared	Yes
Linux - Container Builds	3-blue.shared.runners-manager.gitlab.com/default	docker;east-c;gce;git-annex;linux;mongo;mysql;postgres;ruby;shared	Yes
Linux - Container Builds	4-blue.shared.runners-manager.gitlab.com/default	docker;east-c;gce;git-annex;linux;mongo;mysql;postgres;ruby;shared	Yes
Linux - Container Builds	5-blue.shared.runners-manager.gitlab.com/default	docker;east-c;gce;git-annex;linux;mongo;mysql;postgres;ruby;shared	Yes
Windows - Shell Builds	windows-shared-runners-manager-1	shared-windows;windows;windows-1809	No
Windows - Shell Builds	windows-shared-runners-manager-2	shared-windows;windows;windows-1809	No
macOS - Shell Builds	macOS shared runner (primary cluster)	primary;shared-macos-amd64	No

Available Tier

• Free

Links / references

AS-IS Workflow (Non-Empty Pipeline State)

PM mockups

Mockups

---	--
1.Change navigation to Runners view
2.Catalog view

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.

added devopsverify grouprunner sectionops labels

added to epic &2426 (closed)

changed title from Create design for GitLab SaaS Premium Machine Types Catalog to Create design for GitLab SaaS Runners Premium Machine Types Catalog

changed title from Create design for GitLab SaaS Runners Premium Machine Types Catalog to Design: Create design for GitLab SaaS Runners Premium Machine Types Catalog

added workflowdesign label

added typefeature label

changed the description

marked this issue as related to #354155

changed epic to &6867 (closed)

changed the description

changed the description

mentioned in issue gitlab-org/quality/triage-reports#7353 (closed)

added [Deprecated] Category:Runner label

changed the description

removed workflowdesign label

added workflowvalidation backlog label

added [Deprecated] Category:Runner Fleet label

added GitLab Free label

changed title from Design: Create design for GitLab SaaS Runners Premium Machine Types Catalog to Design: Create design for GitLab SaaS Runners Premium Machine Types

changed the description

changed milestone to %15.2

added candidate15.2 label

added [deprecated] Accepting merge requests label

changed epic to &2426 (closed)

changed title from Design: Create design for GitLab SaaS Runners Premium Machine Types to Design: Create design for expanded catalog of GitLab SaaS Runner machine types

changed the description

removed candidate15.2 label

changed milestone to %15.4

added candidate15.4 label

changed milestone to %15.5

removed candidate15.4 label

added candidate15.5 label

assigned to @gdoyle

changed the description

Priority questions

@DarrenEastman Thanks for assigning me. I have some questions:

• I see this is still in workflowvalidation backlog, did you validate this already? If so, can you link me to the research?
• Where does this sit in priority to the Category Maturity Scorecard for Runner Fleet? I have that planned for the next 2 milestones, so I wouldn't be able to get the design ready for this until 15.6, as it'll need to go through workflowsolution validation most likely (assuming we don't have research to support this already).
• Where does this sit in priority to MVC of runner job queues?

Scope of this issue

I'd like to define and reduce the scope of this MVC as much as possible @DarrenEastman .

• Can we start with providing users with the information about what machine type their runner is using first?
• It looks like this issue is considering the following use cases:
  • Create a new runner and select the machine type when I'm creating it
  • See the machine type of an existing runner
  • Edit the machine type of an existing runner
  • Am I missing any? Each one of these use cases should be their own iterations.
• We have not moved or redesigned the project runner view. That should be considered in a separate iteration. This goes back to my first bullet. Otherwise, we'll have to first move the project runner view to match the same views we have for admin and group views, and then add this feature.

@gdoyle Good question - it's a lower priority than the category maturity scorecard. The approach to take in my mind is to re-design the project view and, while doing so, consider how we effectively display an expanded list of instance-level (Shared Runners) to users at the project view for GitLab SaaS. If we find that we can address that with the project view redesign, then a catalog-type concept is unnecessary.

The problem validation is currently driven by our plans to expand the catalog of machine types offered for GitLab SaaS. As we start to do so, it will be more problematic for GitLab SaaS users to determine the available resources that they can use on GitLab SaaS for CI.

Removed target milestone and linked to the new design issue for the project view.

@DarrenEastman Thanks for clarifying! I'm going to take a stab at updating the description and we can discuss further in our 1:1. I did mark the design for the new project runners view as blocking this for now.

I scoped this down to focus on:

effectively display an expanded list of instance-level (Shared Runners) to users at the project view for GitLab SaaS

I assume this was talking about their existing pool of shared runners that they use. I pulled the following information out and we can create separate issues for these:

• As a GitLab SaaS CI user, I want to be able to quickly use any available Runner machine type to run a CI job.

This sounds like you want to be able to create a runner using a specific machine type. This should be taken on in a new issue.

• Also, the machine type information only exists deeply nested in our docs, which had led users to believe that there currently are no other options.

I was going to add this to the problem section of this issue, but realized that this itself could be its own iteration. It isn't clear to users that we offer so many different types of runner build machines and we should make that more prominent in another iteration.

marked this issue as related to #339258 (closed)

changed milestone to %15.6

removed candidate15.5 label

added candidate15.6 label

marked this issue as related to #367394 (closed)

changed the description

mentioned in issue #367394 (closed)

removed candidate15.6 label

removed milestone %15.6

changed title from Design: Create design for expanded catalog of GitLab SaaS Runner machine types to Include information about GitLab SaaS Runner machine types for a pool of shared runners

changed the description

added GitLab Premium GitLab Ultimate direction documentation labels

changed the description

changed the description

Thanks for working on this @gdoyle! We've removed the Seeking community contributions label to avoid having multiple people working on the same issue.

removed [deprecated] Accepting merge requests label

changed the description

changed milestone to %Backlog

changed the description

@tmaczukin From the Runner SaaS call - this is the issue where are discussing the problem of users on GitLab.com getting visibility into available Shared Runner Types.

Thanks @DarrenEastman.

Let me first refrain my request for discover runners page, as it definitely fits this issue

The AS-IS description clearly shows it, as the first step in this already non-ideal process requires you to have maintainer access to enter runner settings. If you're not a project maintainer you're up to try-and-guess or you need to request maintainers help to find out what runners you even can consider.

So this would be the first big requirement - a page that is available for everyone with developer permissions and above when a read-only list of all runners available in the project context are listed.

Now, for what information we would like to have there, a lot of good improvements were already done on the new admin and group runner list pages. I think that same view, stripped from all the "management" features (like delete button, pause button, edit button etc.) would be a good start.

A possibility to open runner details view (again - read-only in this context) would be also a good thing. The listing page have a limited space capacity. There will be always some information that could be useful, but we would be unable to fit it on the listing while persisting it clean and readable. So the current "new" listing view that we have, stripped from all the management features and with a possibility to open a read-only "runner details" page.

As for the details, we again have discussed recently a lot of nice changes for the runner details view (I don't remember if these are already available or not). And this would be a very good starting point. From a developer perspective I'd definitely like to see:

• information about the executor
• information about the os/architecture
• tag list
• runner version
• run-untagged state
• protected state

This are the absolutely basic information that one needs to be able to make a reasonable choice.

From the maintainer/group owner (and more general - team management, which may be not a technical role with GitLab account) perspective, for instance runners it would be also good to show information about the CI/CD Pipeline Minute factors assigned to the runners. So that I can make a reasonable choice whether I want to use a specific runner with a specific configuration that costs me more than another runner.

There is also one thing that we don't currently have and would be nice to introduce - a description of the runner. In fact, the description field in the database is already used to store the name of the runner (historical reasons behind this, we can talk about details if you'd like to know why it was done like that). But no matter how we would name it, we should create a way for a runner owner to describe the runner. In our GitLab.com example, we could use that space to share with the users that This runner will execute job on a n1-standard-1 VM, with a 25GB SSD attached disk and something, and something .... Such information is not present at all for now and this is part of the reason why the user needs to even bother about going to our documentation.

The problem with documentation is that:

1. It's easy to get out-of-date.
2. It lives in a separate context - even if we will link it user have to go to another page and read through multiple paragraphs to pick out the important details.

While there is no promise that someone updating runner configuration will also update the description, the information here lives in a way closer and more connected place so the chance that it will be in-sync is higher. And as this can be easily showed on the "runner details" page, we remove a need to switch context and go to another page in the documentation to seek the details.

@tmaczukin This is great insight thanks!!

@gdoyle One nuance that I had not considered in these discussions focused on the user persona, but more importantly, as Tomasz points out, is that a Sasha user persona needs "maintainer access to enter runner settings".

So there is a role (access level) consideration as we think about the project level views.

Now, for what information we would like to have there, a lot of good improvements were already done on the new admin and group runner list pages. I think that same view, stripped from all the "management" features (like delete button, pause button, edit button etc.) would be a good start.

Thanks for that insight @tmaczukin and @DarrenEastman for the tag! We have Make the project runners UI consistent with the... (#339258 - closed) open which will be our first iteration at this.

From a developer perspective I'd definitely like to see:

• information about the executor
• information about the os/architecture
• tag list
• runner version
• run-untagged state
• protected state

We can validate this with other developers as well, but my assumption was that we'd want to show more data than what we are showing in the project runners view today, and your insights validate that! We'd likely add this as an iteration after just replacing the project runners with a table.

So this would be the first big requirement - a page that is available for everyone with developer permissions and above when a read-only list of all runners available in the project context are listed.

Even removing runners from settings into its own page in a project would help with this, as developers can't see settings of a project. I need to create a separate issue for this.

There is also one thing that we don't currently have and would be nice to introduce - a description of the runner. In fact, the description field in the database is already used to store the name of the runner (historical reasons behind this, we can talk about details if you'd like to know why it was done like that). But no matter how we would name it, we should create a way for a runner owner to describe the runner. In our GitLab.com example, we could use that space to share with the users that This runner will execute job on a n1-standard-1 VM, with a 25GB SSD attached disk and something, and something .... Such information is not present at all for now and this is part of the reason why the user needs to even bother about going to our documentation

@tmaczukin Is the maintenance notes field we added a little while back a good place for this? That's one of the reasons we added it, so that the owner can add information for other teammates for configuration or informational purposes.

Is the maintenance notes field we added a little while back a good place for this? That's one of the reasons we added it, so that the owner can add information for other teammates for configuration or informational purposes.

@gdoyle I remember about the maintenance notes and I was consciously proposing adding another field

maintenance notes in my mind is a way to share information with other maintainers of the runner. To describe there things that a regular user may not understand or maybe shouldn't even know. While the description field would be added purely to support the regular user of the runner.

Think about the instance runners on GitLab.com case - a regular user may be not interested in the fact that Slack channel #f_linux_shared_runners is the best place to ask questions, nor that #g_runner group is the one responsible for this service. A regular user can't do anything with such information. People may want to add information about why a certain configuration is set or why a specific cost factor is defined - some of these may be confidential and should be not shared outside of the dedicated group.

At the same time, it would be nice to describe:

• that the runner supports Docker-in-Docker
• what are the CPU/memory/disk size specs of the machine where job is executed
• what is the default image used by the Docker executor configured for this runner
• etc.

These all are mostly not important for the maintainer (as we can check our configuration manually at the source - in chef or on the runner manager node) while are the only way to give some data to the user.

Just compare this to the User object we have - we also have two separate description field. One is for the user - users may describe themselves, what they do, where they work, what they like... basically anything they want to share with others about themselves. This is visible to all. At the same time we have the admin notes field - this one is not visible to other users - even the related user itself can't see it. It's dedicated for GitLab instance admins to leave notes about the user (for example - why the user was banned and why the account should be not unlocked).

I'm talking about exactly same difference but in context of runners management - not user management

Even removing runners from settings into its own page in a project would help with this, as developers can't see settings of a project. I need to create a separate issue for this.

If this page will be accessible to all (with features on it controlled by the permission model) then I'm all for it!

@tmaczukin Thanks for the explanation, that makes sense! We'll have to consider the different UI fields we have for runners today including description and maintenance notes and see what the best solution would be to collect & display this information using UX solution validation. This thread definitely gave me some ideas though

changed the description

changed epic to &6867 (closed)

mentioned in issue gitlab-com/Product#4625 (closed)

removed [Deprecated] Category:Runner label

unassigned @gdoyle

mentioned in issue #384179 (closed)

mentioned in issue #329393

changed epic to &10799

added 1 deleted label and removed [Deprecated] Category:Runner Fleet label

added sectionci label and removed sectionops label

added 1 deleted label

mentioned in issue gitlab-org/quality/triage-reports#16733 (closed)

changed title from Include information about GitLab SaaS Runner machine types for a pool of shared runners to Include information about GitLab.com Runner machine types for a pool of shared runners

added Category:Fleet Visibility label

mentioned in issue gitlab-com/Product#13319 (moved)

mentioned in issue #458293

removed GitLab Ultimate label

removed GitLab Premium label