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

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.

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

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.