Specifying a Custom Runner in Your GitLab CI/CD Pipeline: A Step-by-Step Guide

In the fast-evolving world of software development, continuous integration and deployment (CI/CD) have become essential for teams looking to automate their testing and deployment processes. GitLab CI/CD is a powerful tool that offers this automation, and one of its core components is the GitLab Runner. This guide provides a step-by-step approach to specifying a custom runner in your GitLab CI/CD pipeline, focusing on integration with Google Cloud. From understanding the role of runners to configuring and managing them, this guide covers all you need to know to enhance your CI/CD workflow.

Table of Contents

Key Takeaways

  • GitLab Runners are crucial for executing the jobs defined in your CI/CD pipeline, and they can be tailored to meet specific project needs and environments, such as Google Cloud.
  • Registration tokens are necessary for setting up custom runners, and these can be obtained from the CI/CD settings within your GitLab project.
  • The runner can be configured to execute untagged jobs, which simplifies the process for simple CI/CD pipelines that do not utilize job tags for runner selection.
  • Security is paramount when configuring runners, especially when they handle sensitive data like SSH keys for deployment; runners should be set up with security best practices in mind.
  • Regular updates and monitoring are recommended for maintaining custom runners, ensuring they perform optimally and securely within your CI/CD infrastructure.

Understanding GitLab Runners

Understanding GitLab Runners

The Role of Runners in CI/CD

In the realm of continuous integration and continuous deployment (CI/CD), GitLab Runners are the workhorses that execute the jobs defined in your .gitlab-ci.yml file. They are essential for automating the testing, building, and deployment of your code. Runners can be thought of as agents that pick up jobs through the GitLab CI/CD pipeline and run them as specified.

Runners come in various flavors, each tailored to different environments and use cases. For instance, you might use a shared runner for general tasks, while a specific runner could be dedicated to heavy-duty jobs or jobs that require special security considerations. Here’s a quick rundown of runner types:

  • Shared Runners are available to all projects in a GitLab instance.
  • Group Runners are dedicated to a group of projects.
  • Specific Runners are associated with specific projects and can be fine-tuned for their needs.

It’s crucial to isolate environments by using separate runners or runner tags for development (DEV) and production (PROD) pipelines. This practice enhances security by ensuring that a compromise in the DEV environment doesn’t directly impact PROD.

When setting up your CI/CD pipeline, selecting the right type of runner for your project’s needs is a foundational step. This choice impacts not only the efficiency of your pipeline but also the security and scalability of your CI/CD process.

Types of Runners Available

GitLab CI/CD pipelines are powered by Runners that execute your jobs. Runners can be specific to a project, assigned to a group, or set up as a shared resource across multiple projects. Depending on your needs, you can choose between Shared Runners provided by GitLab, which are great for getting started quickly, and Custom Runners that offer more control and flexibility.

GitLab Ultimate users have access to advanced features and support for their Custom Runners, but even without the premium tier, you can still make the most out of the various types of Runners available:

  • Shared Runners: Ideal for smaller projects or for anyone just starting out with CI/CD.
  • Group Runners: Best for projects within a group that have similar requirements.
  • Specific Runners: Dedicated to a single project for specialized configurations.

Remember, the choice of Runner affects not only the performance of your CI/CD pipeline but also the security and cost. It’s crucial to select the right type of Runner to match your project’s needs.

Security Considerations for Runners

When configuring your GitLab Runner, it’s imperative to prioritize security to protect your CI/CD pipeline. Isolating environments is a key step; ensure that runners used for development are separate from those in production to prevent cross-contamination. Access controls are fundamental; limit who can interact with critical branches and CI/CD variables to mitigate unauthorized changes.

Runner security is essential for maintaining the integrity of your operations. Strong authentication and secure machine configurations are non-negotiable to prevent potential breaches. Remember, using shared runners can expose your deployment jobs to unknown systems, which is why registering your own server as a GitLab runner is a safer alternative.

Configuring GitLab Runner for optimized performance and security is not just about following a checklist; it’s about integrating security into your DevSecOps culture to ensure continuous protection throughout the development lifecycle.

Preparing Your Project for Custom Runners

Preparing Your Project for Custom Runners

Creating a New Project in GitLab

To kickstart your journey with GitLab CI/CD, the first step is to create a new project. This is where your code will reside and where the pipelines will be executed. Here’s how to get started:

  1. Log in to your GitLab instance and click on New project.
  2. On the ‘Create new project’ screen, select ‘Create blank project’.
  3. Enter a meaningful Project name that reflects your application or service.
  4. If needed, specify a Project deployment target.
  5. Choose the appropriate Visibility Level—Private or Public—based on who needs access to the project.
  6. Click ‘Create project’ to finalize the setup.

Once created, you’ll be taken to the Project’s overview page, where you can begin to populate your repository with code and set up your CI/CD pipeline.

Remember, the project name and visibility are crucial decisions that affect how your team collaborates and how your code is protected. Choose wisely to align with your project’s goals and security requirements.

Navigating to CI/CD Settings

Once you’ve created your project in GitLab, the next step is to configure your CI/CD pipeline. To do this, navigate to your project’s settings by clicking on Settings and then selecting the CI/CD option. This will take you to the CI/CD configuration page where you can manage various aspects of your pipeline.

In the CI/CD settings, you’ll find a plethora of options to tailor your pipeline to your project’s needs. This is where you can expand the Runners section to add or manage your custom runners.

Here’s a quick guide to get you to the right place:

  1. Click on the Settings menu within your project.
  2. Select the CI/CD submenu.
  3. Scroll down to the Runners section.

Remember, if you’re using GitLab Premium, you’ll have access to additional features and settings that can enhance your CI/CD experience. It’s worth exploring these options to fully leverage the capabilities of your custom runner.

Locating the Registration Token

To set up your custom runner, you’ll first need to obtain a unique registration token from your GitLab project. This token is essential for securely linking your runner to the project. Navigate to your project’s settings and follow these steps:

  1. Go to Settings > CI/CD and expand the Runners section.
  2. Look for the Project runners area and click on New project runner.
  3. After setting up, you’ll see the registration token and the GitLab URL. Copy both to a safe place; they’re vital for the upcoming registration command.

Remember, the registration token acts as a password, so keep it confidential. Once you have the token and the URL, you’re ready to move on to installing and registering your GitLab runner.

Registering Your Custom Runner

Registering Your Custom Runner

Installing the GitLab Runner

To set up a custom GitLab Runner, you’ll need to install the runner software on your designated machine. Installation steps vary depending on your operating system, but the process generally involves downloading the package and running an installation command.

For example, on a Debian-based system, you would execute:

sudo apt-get install gitlab-runner

After installation, the system will prompt you for a password to proceed. It’s crucial to ensure that the machine meets the necessary requirements and has network access to your GitLab instance.

Remember to verify the installation by checking the GitLab Runner version post-installation to ensure it matches the latest or required version for your project.

Once the GitLab Runner is installed, the next step is to register it with your GitLab project using the registration token obtained from your project’s CI/CD settings. This process will associate your runner with your project and allow it to start picking up jobs. Registration is a critical step, as it ties your runner to the specific tasks it will execute.

Executing the Registration Command

Once you’ve located your registration token, it’s time to register your runner. In your terminal, execute the gitlab-runner register command with the necessary parameters. This will link your custom runner to your GitLab project. Here’s an example of the command you might use:

sudo gitlab-runner register -n --url https://your_gitlab.com --registration-token project_token --executor docker --description "My Custom Runner" --docker-image "docker:stable" --tag-list my-tag

The parameters are straightforward:

  • -n runs the command non-interactively.
  • --url is your GitLab instance URL.
  • --registration-token is the token from your project’s settings.
  • --executor specifies the environment the runner will use.
  • --description sets a name for your runner in GitLab.
  • --docker-image defines the default Docker image.
  • --tag-list allows you to assign tags for job filtering.

After successful registration, you should see a confirmation message. Verify the runner’s presence in your GitLab project’s settings under the Runners section.

Remember, as of GitLab Runner 15.6, the use of registration tokens in the register command is deprecated. Future versions will require an authentication token, which you can learn more about in the GitLab issues tracker.

Adding Tags and Descriptions

Once you’ve executed the registration command, it’s time to add tags and descriptions to your custom runner. Tags are essential for categorizing your runners and controlling which jobs they pick up. For instance, you might have tags like backend, frontend, or deploy to specify the type of job each runner is best suited for. Descriptions, on the other hand, provide a human-readable identifier to help you quickly recognize the runner’s purpose.

To configure your GitLab Runner, you’ll need to edit the config.toml file. This is where you can set parameters such as concurrent for specifying the number of jobs the runner can handle simultaneously, and executor to define the environment in which the jobs will run. Remember to carefully assign tags and descriptions that reflect the runner’s intended use-case to ensure efficient performance.

It’s crucial to maintain a clear and organized structure for your runners. Proper tagging and clear descriptions not only streamline the job execution process but also simplify runner management in the long run.

Configuring the Runner for Google Cloud

Configuring the Runner for Google Cloud

Specifying the Environment

When configuring your GitLab Runner for Google Cloud, specifying the environment is a critical step. It’s essential to define the context in which your CI/CD jobs will run, as it directly impacts the security and efficiency of your pipelines. For instance, using a GitLab Runner with Docker can simplify the process by creating isolated environments, which is key to optimizing your workflows.

To ensure proper environment segregation, consider the following steps:

  • Define environment variables that are specific to your project’s needs, such as DBT_URL or DBT_JOB_BRANCH.
  • Compose environment variables from predefined variables to represent different stages like staging and production.
  • Isolate environments to protect your build environment and prevent compromising your production pipeline.

Remember, protecting your build environment is crucial. Isolation helps to prevent any security breaches that could affect multiple stages of your pipeline.

By registering and configuring your Runner appropriately, you streamline your software development process and maintain a high level of security across various environments.

Setting Up Google Cloud Project Prerequisites

Before diving into the registration and configuration of your GitLab Runner on Google Cloud, it’s essential to ensure that your project meets the necessary prerequisites. Ensure that billing is enabled for your Google Cloud project, as this is a fundamental requirement for resource allocation and service usage.

Next, verify that you have the gcloud CLI tool installed and authenticated with the Owner IAM role. This step is crucial for managing resources and permissions within your Google Cloud project. Additionally, having the Terraform CLI tool installed will streamline the process of provisioning infrastructure.

To facilitate a smooth setup, follow these steps:

Enable billing on your Google Cloud project.
Authenticate the gcloud CLI tool with the necessary permissions.
Install the Terraform CLI tool.

Remember, these steps are a one-time setup for each Google Cloud project. Once completed, you can proceed to install and register your GitLab Runner using the provided Terraform scripts, which leverage the GitLab Runner Infrastructure Template (GRIT) for efficient provisioning.

Installing and Registering with Terraform

To integrate your custom runner with Google Cloud, Terraform plays a crucial role. It automates the provisioning of the necessary infrastructure using the GitLab Runner Infrastructure Toolkit (GRIT). Before proceeding, ensure that your Google Cloud project has billing enabled and that you have the gcloud CLI tool authenticated with the Owner IAM role.

Prerequisites for Terraform Setup:

  • Billing enabled for Google Cloud project
  • gcloud CLI tool with Owner IAM role authentication
  • Terraform CLI tool installed

Begin by configuring your Google Cloud project to meet the required services, service account, and permissions. This setup is a one-time process per Google Cloud project.

Once the prerequisites are met, you can execute the Terraform script provided in the GitLab Runner setup instructions. This script leverages GRIT to create the infrastructure needed to run your custom runner manager on Google Cloud. Remember to review and customize the script according to your project’s specific needs for a seamless integration.

Fine-Tuning Your Runner Settings

Fine-Tuning Your Runner Settings

Adjusting Runner Configuration

Once your custom runner is registered, you’ll need to fine-tune its configuration to match your project’s requirements. Adjusting the config.toml file is crucial for optimizing the runner’s performance and behavior. For instance, you might want to modify the concurrent setting to align with the number of runners you have. If you have three runners, set concurrent to at least 3 to avoid bottlenecks.

Remember, changes to the runner’s configuration take effect immediately if the runner is active. Otherwise, they will apply upon the next start.

Here’s a quick checklist for common adjustments:

  • Verify the concurrent value is appropriate for your setup.
  • Customize job execution behavior with executor parameters.
  • Set up environment variables specific to your project’s needs.
  • Review advanced settings for networking or caching if necessary.

Enabling Untagged Job Execution

By default, GitLab Runners are configured to pick up jobs that have specific tags associated with them. This is a way to ensure that certain jobs are executed by the appropriate runners. However, there might be instances where your CI/CD pipeline does not utilize tags, and you want your custom runner to execute all jobs, regardless of tagging.

To enable your runner to execute untagged jobs, navigate to your project’s settings in GitLab. Under the CI/CD section, find your runner and click the pencil icon to edit its settings. Here, you’ll find the option to ‘Run untagged jobs’. Check this box to allow the runner to pick up any available job.

Remember, allowing a runner to execute untagged jobs means it will process any job that doesn’t have a specific runner assigned. This can be useful for simple pipelines but consider the implications for more complex workflows.

After making this change, it’s a good idea to verify that your runner is properly configured. If you encounter the message "This job has not started yet" in the Pipelines -> Build Job section, it could indicate an issue. Additionally, check the Admin area > CI/CD (not the settings>CI/CD) > Runners to ensure your runner is both enabled and online.

Updating Runner Descriptions

Keeping your runner descriptions up-to-date is crucial for maintaining clarity within your CI/CD pipeline. When you change a runner’s purpose or environment, update its description immediately to reflect these changes. This practice helps team members quickly identify the appropriate runner for their jobs.

To update a runner’s description, navigate to your project’s Settings > CI/CD and expand the Runners section. Here, you’ll find a list of all runners associated with your project. Click the pencil icon next to the runner you wish to update, and you’ll be presented with an option to modify its description.

Remember, a descriptive and accurate runner name simplifies the process of selecting the right runner for specific jobs.

It’s also a good idea to include relevant tags when updating the runner’s description. Tags act as filters, ensuring that jobs are picked up by the correct runner. Below is an example of how to format the runner’s description and tags:

["token"]: Enter a description for the runner:
[ip-10-10-45-212]: runner-attackbox
Enter tags for the runner (comma-separated):
production, staging

Launching the Runner and Verifying Connection

Launching the Runner and Verifying Connection

Starting the Runner Service

Once you’ve successfully registered your GitLab Runner, it’s time to start the service. This is typically done using the system’s service manager. For example, on a system with systemd, you would use sudo systemctl start gitlab-runner to get the runner up and running. Remember, if the runner was already running, the new configuration should be automatically reloaded.

After starting the service, the runner may take a moment to connect. The runner manager will authenticate using the runner authentication token and should appear online within a minute, ready to receive jobs.

To ensure your runner is functioning correctly, you can check its status. On a systemd-based system, use sudo systemctl status gitlab-runner. The output should indicate whether the runner is active and running. If you encounter any issues, refer to the troubleshooting section for guidance.

Checking Runner Status in GitLab

Once you’ve started your GitLab Runner, it’s crucial to confirm that it’s properly connected to your GitLab instance. Navigate to your project’s settings in GitLab, and select the Runners section to view the status of your runners. You should see your newly registered runner listed as active. If the runner is correctly configured, the status should display as ‘active (running)’ indicating that it’s ready to pick up jobs.

Ensure that your runner is not only active but also not encountering any errors. An active runner that is experiencing issues will not be able to process jobs effectively.

If your runner does not appear or shows as inactive, double-check the registration steps and ensure that the GitLab Runner service is running on your server. You can verify the runner’s service status using the command systemctl status gitlab-runner. The expected output should confirm that the service is active and running.

  • Refresh the Runners page in GitLab after starting the service.
  • Look for the green circle next to your runner, indicating it’s operational.
  • Check for any error messages that might indicate a problem.

Remember, a properly functioning runner is key to a smooth CI/CD process. If you encounter any issues, consult the troubleshooting section for common problems and their solutions.

Troubleshooting Common Issues

When launching your custom GitLab Runner, you might encounter some hiccups along the way. Common issues can range from configuration errors to network problems, and each requires a different approach to solve. Here’s a quick checklist to help you troubleshoot effectively:

  • Ensure that the Runner is correctly installed and the service is running.
  • Verify network connectivity between the Runner and the GitLab server.
  • Check for accurate Runner registration by reviewing the configuration file.
  • Look for error messages in the Runner’s logs, which can provide clues to the issue.

Remember, a methodical approach to troubleshooting will save you time and reduce frustration.

If you’ve gone through the checklist and the problem persists, consider consulting the GitLab documentation or community forums. The wealth of knowledge available can often illuminate the path to a solution. Using GitLab Runner in CI/CD pipelines enables seamless integration of automated testing and deployment, scaling pipelines efficiently, troubleshooting common issues, and optimizing performance.

Integrating Runners into Your CI/CD Pipeline

Integrating Runners into Your CI/CD Pipeline

Editing .gitlab-ci.yml for Runner Integration

Integrating a custom runner into your GitLab CI/CD pipeline requires editing the .gitlab-ci.yml file. This file defines the structure and order of the pipeline and determines which runner will execute each job. Start by specifying the tags associated with your custom runner in the job definitions. Tags are crucial as they direct jobs to the appropriate runner, especially when multiple runners are available.

Tags can be set globally or per job. For a global setting, add the tags: keyword under the default: section. To specify tags for an individual job, include them under the job definition:

stages:
  - build
  - test
  - deploy

default:
  tags:
    - my-custom-runner

build_job:
  stage: build
  script:
    - echo "Building the project..."
  tags:
    - docker
    - linux

Remember to use CI/CD variables for sensitive information, such as API keys and passwords, to maintain security within your pipeline.

After setting up the tags, ensure that the runner is properly registered and has the correct permissions to execute the jobs. Refer to the Runner description and Configuration sections in your GitLab project settings to review and adjust the runner’s details as needed.

Managing Runner Behavior with Tags

Tags are a powerful feature in GitLab CI/CD that allow you to control which runners pick up which jobs. By assigning specific tags to your runners, you can ensure that only the appropriate runners execute certain jobs. This is particularly useful when you have multiple runners with different capabilities or environments.

Use tags to limit runner access to sensitive jobs. For example, you might have a runner that is configured to handle deployment jobs. By tagging this runner with deployment, you can configure your .gitlab-ci.yml to only use runners with this tag for deployment jobs, enhancing security and consistency.

Here’s how to manage runner tags effectively:

  • Assign tags to runners when registering them with GitLab.
  • Use the tags in your .gitlab-ci.yml to specify which runners should execute which jobs.
  • Regularly review and update tags to reflect changes in your CI/CD pipeline requirements.

Remember, tags are not just for organization; they’re a critical part of access control and permissions in your CI/CD workflow.

Ensuring Secure Deployment with SSH Keys

Ensuring secure deployment in your CI/CD pipeline is critical, and using SSH keys is a standard practice for authenticating to servers without the need for passwords. Generate a 4096-bit SSH key with ssh-keygen -b 4096 to create a secure key pair. Remember, the private key should be kept confidential and never leave the system it was generated on.

To authorize the SSH key for the deployer user, append the public key to the authorized_keys file with cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys. This step is crucial for allowing secure connections without manual password entry.

For the deployment job, ensure that the private key has the correct permissions set. Use chmod og= $ID_RSA to restrict access so that only the owner can use it. This is not just a best practice; SSH will refuse to work with the private key if the permissions are too open. Additionally, install the openssh-client if it’s not already present to enable SSH commands within your pipeline.

Here’s a quick checklist for SSH key integration in your GitLab CI/CD pipeline:

  • Generate SSH key pair with ssh-keygen -b 4096
  • Append public key to authorized_keys on the server
  • Set correct permissions on the private key
  • Install openssh-client on the CI/CD environment
  • Store the private key in a GitLab CI/CD variable for secure access

By following these steps, you’ll ensure that your deployment process is both secure and efficient, paving the way for a sustainable and extensible CI/CD setup.

Best Practices for Managing Custom Runners

Best Practices for Managing Custom Runners

Regularly Updating Runner Software

Keeping your GitLab Runner up-to-date is crucial for both security and access to the latest features. Regular updates ensure compatibility with the latest GitLab releases and minimize potential vulnerabilities. It’s recommended to establish a routine for checking and applying updates to your runners.

To streamline the update process, consider the following steps:

  1. Monitor the official GitLab Runner repository for new releases.
  2. Schedule a maintenance window to apply updates with minimal disruption to your CI/CD workflow.
  3. Test the updated runner in a staging environment before deploying to production.

Remember, an outdated runner might not only miss out on improvements but could also become a security liability.

Lastly, automate the update process where possible to reduce manual oversight and ensure your runners are always running the latest version. Automation can be achieved through scripting or by using configuration management tools.

Monitoring Runner Performance

Keeping a close eye on the performance of your custom runners is crucial for maintaining an efficient CI/CD pipeline. Regular monitoring can help you identify and resolve issues before they escalate. Utilize the Metrics feature in GitLab to track the performance of your runners. You can access this by navigating to Monitor > Metrics in your project’s sidebar. Here, you’ll find valuable insights into the runner’s behavior, such as job processing times and queue lengths.

To ensure optimal performance, consider the following points:

  • Review the polling interval settings to avoid performance bottlenecks.
  • Adjust the concurrent setting in config.toml to match the number of runners.
  • Keep an eye on the runner manager’s connection status to quickly address any delays in job processing.

By proactively managing these aspects, you can maintain a streamlined workflow and prevent potential long polling issues.

Remember, a well-monitored runner is a reliable asset in your CI/CD arsenal. Regular checks and tweaks based on the metrics observed will lead to a more robust and responsive pipeline.

Handling Runner Security and Access

Ensuring the security of your GitLab Runners is not just a best practice; it’s a necessity to protect your CI/CD pipeline from unauthorized access and potential breaches. Limit runner access by using tags to specify which runners are allowed to execute jobs. This way, you can control that only trusted runners with the appropriate tags can run jobs on sensitive branches like the main branch.

Access control measures are fundamental. Strong authentication protocols and permission settings should be in place to restrict who can modify CI/CD configurations, including the .gitlab-ci.yml file. It’s also important to limit physical and network access to the machines hosting your GitLab Runners to authorized personnel only.

Monitoring and alerting mechanisms should be established to detect and respond to any unauthorized access attempts or suspicious activities.

Remember, runner security is not just about the software configuration; it’s also about the environment in which your runners operate. Segregate your environments to prevent cross-contamination between development and production builds. By doing so, you ensure that a compromise in a less secure environment doesn’t lead to a breach in a more sensitive one.

Conclusion

In this guide, we’ve walked through the detailed process of specifying a custom runner for your GitLab CI/CD pipeline. From creating a project and obtaining a registration token to configuring the runner in a Google Cloud environment, we’ve covered the essential steps to ensure your CI/CD jobs are executed efficiently. Remember, while setting up a runner may seem intricate at first, it’s a one-time setup that can significantly streamline your build and deployment processes. With your new runner now ready to tackle untagged jobs, your build automation is set to become more robust and tailored to your project’s needs. Keep this guide handy for future reference, and happy coding!

Frequently Asked Questions

What is a GitLab Runner and why do I need one?

A GitLab Runner is a lightweight, standalone service that works with GitLab CI/CD to run jobs in a pipeline. You need a runner to execute the scripts defined in your .gitlab-ci.yml file, effectively automating your build, test, and deployment processes.

What are the different types of GitLab Runners?

GitLab Runners can be of three types: Shared, Group, and Specific. Shared Runners are available to all projects in a GitLab instance. Group Runners are available to all projects within a group. Specific Runners are associated with specific projects and are typically used for specialized environments.

How do I secure my GitLab Runner?

To secure your GitLab Runner, ensure it’s updated regularly, use secure connections like SSH, limit its access to trusted networks, and follow the principle of least privilege by granting it the minimal access needed to perform its tasks.

How do I find the registration token for a GitLab Runner?

To find the registration token for a GitLab Runner, go to your project’s Settings > CI/CD, expand the Runners section, and you’ll find the token in the ‘Set up a specific Runner manually’ section.

How do I register a new GitLab Runner?

To register a new GitLab Runner, install the GitLab Runner software, execute the registration command with the registration token, and configure the runner with the appropriate tags and description.

Can GitLab Runners be used with cloud services like Google Cloud?

Yes, GitLab Runners can be configured to work with cloud services like Google Cloud. You’ll need to set up your cloud environment and use tools like Terraform to automate the runner’s deployment and registration.

What should I do if my GitLab Runner is not taking jobs?

If your GitLab Runner is not taking jobs, check the runner’s status in GitLab, ensure it’s properly configured and enabled, and verify that it’s not paused or stuck. Also, check for any errors in the runner’s logs for troubleshooting.

How can I integrate a GitLab Runner into my CI/CD pipeline?

To integrate a GitLab Runner into your CI/CD pipeline, edit your .gitlab-ci.yml file to specify the runner tags that match the tags assigned to your runner. This ensures that your pipeline jobs are picked up by the correct runner.

You may also like...