GitLab: Is it possible to run pipeline on a specific runner?

Question

Is it possible to run a pipeline on a specific runner? (not using tags)

Is it feasible to use environments, or even gitlab runner exec maybe?

---

Scenario:

Have an existing project with multiple runners already attached to it (specific project token used to register the runner) and has it's own associated tags (so can't change these either).

I'm adding a new runner, however need to test it first to ensure it works, but I need to force the pipeline to build on this machine, without changing any tags, or specific project of the runner.

Answer 1

You have two mechanisms by which you can attempt to isolate a new runner for testing:

1. use tags and private runner attachment (already called out)
2. use the gitlab-runner exec verb directly on the runner
3. canary the runner for a single build only

Option 1

use tags and private runner attachment (already called out).

To further expand on this... even in a draconian setup where you can't alter tags and whatnot -- you can always FORK the project.

In your new private fork, you can go to Settings >> CI/CD and override the .gitlab-ci.yml file in the Custom CI Configuration Path under the General Pipelines Settings. This allows you to git cp .gitlab-ci.yml .mycustomgitlab-ci.yml and then simply git add/git commit/git push and you're in business.

Opinion: If you cannot use the mechanisms in place to adjust the tags on the questionable runner and isolate a new forked project, this isn't a technical problem, it is a political problem.

Option 2

Gitlab-runner exec....

Assuming you're using a shell gitlab runner...

1. SSH to the questionable gitlab runner box you're trying to test
2. Clone the repo for the project in question to ... say ... /tmp/myrepo
3. Execute Gitlab-Runner: /path/to/gitlab-runner exec shell {.gitlab-ci.yml target}

See https://docs.gitlab.com/runner/commands/#gitlab-runner-exec and a blog about it at https://substrakt.com/how-to-debug-gitlab-ci-builds-locally/

Option 3

Canary the gitlab-runner for a single build.

You can spin up the gitlab-runner process to do N number of builds and then go back offline. See: https://docs.gitlab.com/runner/commands/#gitlab-runner-run-single

... This is not zero-impact, but will definitely limit the blast radius of any problems.