gitlab runner Specific runner vs Shared runner vs Group runner

Question

As a Sysadmin, I'm using gitlab as git server and some docker server as deploy servers. We have many projects on gitlab, Now I decide to use gitlab runner as a simple CI/CD ro automate deploy our projects.

Now i got mixed up by some concept of runner in below:

• specific runner vs shared runner
• shared runner vs group runner

So now, Which one to use?

Answer 1

GitLab 13.5 (October 2020) adds a feature which also illustrates what shared runners are used for:

Enable instance-level shared runners when viewing groups

GitLab SaaS includes Linux and Windows runners, which are easy to use agents that run your GitLab CI/CD pipeline jobs. These runners, visible in the GitLab.com UI as “shared runners”, are enabled by default and can be disabled for each project.

However, some organizations require their CI/CD jobs to run only on self-managed runners, and so disabling the use of instance-level shared runners on each project resulted in unnecessary administrative overhead.

Now administrators can enable or disable shared runners at the group level. Administrators can also allow groups to override the global setting and use shared runners on a project-by-project basis.

See Documentation and Issue.

---

And, regarding group runners:

See GitLab 14.10 (April 2022)

Expanded view of group runners

Group runners are now displayed in an expanded view, where you can more easily administer and manage the runners associated with the namespace.

To view the new UI, on the left sidebar, select CI/CD. This view includes the number of online, offline, and stale runners associated with the group and subgroups.

See Documentation and Issue.

As opposed to:

GitLab Runner 14.10

GitLab Runner is the lightweight, highly-scalable agent that runs your build jobs and sends the results back to a GitLab instance.

GitLab Runner works in conjunction with GitLab CI/CD, the open-source continuous integration service included with GitLab.

What's new:

• Configure artifact download path
• Script line timestamp improvements

The list of all changes is in the GitLab Runner CHANGELOG.

See Documentation.

---

GitLab 15.3 (August 2022) brings:

Improved details and editing for group runners

If you’re a group owner, when you’re viewing a runner’s details, the redesigned details page has an improved layout.
The runner’s metadata is displayed more compactly and you can edit the runner from the new view.
These changes help make the experience of managing runners easier and more efficient.

See Documentation and Issue.

---

With GitLab 16.0 (May 2023), you can easily:

Create a group runner as a user

Create an instance runner in the Admin Area as a user

Create an instance runner in the Admin Area as a user

In this new workflow, adding a new runner to a GitLab group requires authorized users to create a runner in the GitLab UI and include essential configuration metadata.
With this method, the runner is now easily traceable to the user, which will help administrators troubleshoot build issues or respond to security incidents.

See Documentation and:

• Issue
• Issue.
• Issue

Answer 2

I might be quite late to answer this question but I want to share my thoughts over the Runners provided by GitLab that can run our CI/CD pipeline jobs.

Current GitLab version - 14.0

GitLab Runners are the application which runs with GitLab CI/CD pipelines to run our jobs. We have three categories of GitLab runners-

Type	Scope	Usage
Shared Runners	Global Level - available to all the groups, subgroups & projects in the GitLab instance	If all the groups & projects inside GitLab instance share similar requirements, we prefer shared runners
Group Runners	Group Level - available to specific groups, subgroups and projects inside the group	Use Group runners when you want all projects in a group to have access to a set of runners. Group runners process jobs by using a first in, first out (FIFO) queue.
Specific Runners	Project Level - available to specific projects	Use Specific runners when you want to use runners for specific projects. For example, when you have: Jobs with specific requirements, like a deploy job that requires credentials. Projects with a lot of CI activity that can benefit from being separate from other runners.

Hope I have helped you to clear your doubts. You can read more on the Gitlab runner documentation about all those runners and their configuration.

Answer 3

Shared Runners are useful for jobs that have similar requirements, between multiple projects. Rather than having multiple Runners idling for many projects, you can have a single or a small number of Runners that handle multiple projects. This makes it easier to maintain and update them. Shared Runners process jobs using a fair usage queue. In contrast to specific Runners that use a FIFO queue, this prevents cases where projects create hundreds of jobs which can lead to eating all available shared Runners resources. Specific Runners are useful for jobs that have special requirements or for projects with a specific demand. If a job has certain requirements, you can set up the specific Runner with this in mind, while not having to do this for all Runners. For example, if you want to deploy a certain project, you can set up a specific Runner to have the right credentials for this. The usage of tags may be useful in this case. Specific Runners process jobs using a FIFO queue. Group Runners are useful when you have multiple projects under one group and would like all projects to have access to a set of Runners. Group Runners process jobs using a FIFO queue.