The tags keyword in a GitLab CI/CD job definition is used to specify which GitLab Runners should execute that job. GitLab Runners are the agents that actually run your CI/CD tasks. When you set up a runner, you can assign it one or more tags. Then, in your .gitlab-ci.yml, you can specify that a job should only be executed by runners that possess certain tags.

This allows you to:

• Designate specific runners for specific types of jobs (e.g., runners with Docker installed, runners on a particular OS like Windows or macOS, runners with access to specific hardware like GPUs, or runners dedicated to deployment tasks).
• Control resource allocation and job execution environments.

Example .gitlab-ci.yml with tags:

YAML

# .gitlab-ci.yml

stages:
  - build
  - test
  - deploy

default:
  image: alpine:latest # A global default image

# Job 1: Requires a runner with the 'docker' tag
build_with_docker_runner:
  stage: build
  tags:
    - docker # This job will only be picked up by a runner that has the 'docker' tag.
  script:
    - echo "--- Building with a Docker-enabled runner ---"
    - echo "This job expects the runner to have Docker capabilities."
    - docker info # Example command that would require Docker
    - echo "Build complete."

# Job 2: Requires a runner with BOTH 'linux' AND 'gpu' tags
gpu_accelerated_tests:
  stage: test
  tags:
    - linux   # Runner must have 'linux' tag
    - gpu     # AND runner must also have 'gpu' tag
  script:
    - echo "--- Running GPU Accelerated Tests ---"
    - echo "This job needs a Linux runner with GPU access."
    - echo "Simulating GPU-intensive computations..."
    - sleep 10
    - echo "GPU tests complete."

# Job 3: No specific tags defined at the job level
# This job can be picked up by:
# 1. Runners that are configured to run untagged jobs.
# 2. Shared runners (if available and configured for the project) that might not require specific tags.
# 3. If 'default:tags:' were defined, it would use those.
generic_script_job:
  stage: test
  # No 'tags:' keyword here
  script:
    - echo "--- Running Generic Script Job ---"
    - echo "This job has no specific tag requirements from the job definition."
    - echo "It can run on any available runner that is allowed to pick up untagged jobs for this project."
    - date

# Job 4: Deployment job, might target specific deployment runners
deploy_to_production_server:
  stage: deploy
  tags:
    - deploy   # Runner must have 'deploy' tag
    - production # AND runner must also have 'production' tag
  script:
    - echo "--- Deploying to Production ---"
    - echo "This job must run on a secure runner designated for production deployments."
    - echo "Deployment scripts would execute here."
    - sleep 5
    - echo "Deployment to production successful."

Code language: PHP (php)

Explanation:

1. tags: Keyword:
   • Used within a job’s definition (e.g., build_with_docker_runner).
   • It takes an array of strings, where each string is a tag.
2. How Runners are Tagged (Background):
   • When a GitLab Runner is registered (by a GitLab administrator or a user setting up a specific runner), it can be assigned one or more tags (e.g., docker, linux, windows, macos, ruby-2.7, gpu, deploy-production).
   • These tags describe the capabilities or purpose of that runner.
3. build_with_docker_runner Job:
   • tags: - docker:
     • This job specifies that it requires a runner which has the tag docker.
     • Only runners that have been configured with the docker tag will be eligible to pick up and execute this job. This is useful if the job needs Docker to build images, run containers, etc.
4. gpu_accelerated_tests Job:
   • tags: - linux - gpu:
     • This job lists multiple tags. For a runner to pick up this job, it must possess ALL the tags listed by the job.
     • So, this job requires a runner that is tagged with linux AND also tagged with gpu. A runner tagged only with linux (but not gpu) would not pick it up.
5. generic_script_job Job:
   • This job does not have a tags: keyword. Its behavior depends on the runner configurations for your project/instance:
     • Untagged Runners: Runners can be configured to pick up jobs that don’t specify any tags (i.e., “run untagged jobs”). If such runners are available to your project, one of them might pick up this job.
     • Shared Runners: If your project has access to shared runners provided by your GitLab instance, their configuration determines if they pick up untagged jobs.
     • default:tags:: If you had a default:tags: section at the top level of your .gitlab-ci.yml, this job would inherit those default tags.
6. deploy_to_production_server Job:
   • tags: - deploy - production:
     • This illustrates a common use case for deploying to a specific environment. You would tag your production deployment runners with deploy and production to ensure only those trusted and specifically configured runners handle such critical tasks.

Key Concepts and Behavior:

• Purpose: To ensure that jobs are executed on runners that have the necessary capabilities, environment, or permissions.
• Matching Logic:
  • A job will only be executed by a runner if the runner has all the tags specified in the job’s tags list.
  • A runner can have more tags than a job specifies. As long as it has the ones the job requires, it’s a match. For example, a runner tagged [docker, linux, fast] can run a job with tags: [docker, linux].
• No Tags in Job: If a job has no tags defined, it can only be picked up by runners that are configured to run untagged jobs.
• Runner Configuration:
  • When registering a runner, you specify its tags.
  • You also configure whether a runner can pick up untagged jobs.
  • Runners can be “shared” (available to multiple projects), “group” (available to projects in a group), or “specific” (registered for a single project).
• default:tags:: You can set default tags for all jobs using the default: top-level keyword: YAMLdefault: tags: - common-runner Job-level tags will override these defaults.
• Order of Tags: The order of tags in the tags list in your job definition, or on the runner, does not matter.

Using tags effectively is crucial for managing a diverse set of CI/CD tasks that may require different operating systems, software dependencies, or security contexts. It gives you precise control over where your jobs run.