Day 6: Configuring GitLab Runners and Job Artifacts

Welcome to Day 6 of our GitLab CI/CD series! Today we're going to dive deeper into GitLab Runners and discuss how to configure jobs to use specific runners and manage job artifacts. Let's get started!

Configuring Jobs to Use Specific Runners

You might recall from yesterday that there are three types of GitLab Runners: shared, group, and specific. Sometimes, you might want a job to only run on a specific type of runner. For example, you might have a job that requires a lot of processing power and should only be run on a specific runner that you've set up with a powerful machine.

To configure a job to use a specific runner, you can use the tags keyword in your .gitlab-ci.yml file. When you register a runner, you can assign it one or more tags, then use these tags in your jobs.

Here's an example of a job that's configured to only run on runners that have the powerful tag:

heavy_lifting_job:
  script: ./run-heavy-lifting-task.sh
  tags:
    - powerful

Understanding and Managing Job Artifacts

Job artifacts are the files that jobs generate. This can include compiled binaries, test results, logs, or any other files that you might want to save.

By default, artifacts are deleted after 30 days, but you can configure this using the expire_in keyword.

To specify artifacts for a job, use the artifacts keyword in your .gitlab-ci.yml file. Here's an example:

test_job:
  script: ./run-tests.sh
  artifacts:
    paths:
      - test-results/
    expire_in: 7 days

This job will run the run-tests.sh script and save the results in the test-results/ directory. These results will be saved as job artifacts and will be deleted after 7 days.

Artifacts are available for download in the GitLab web interface, and can also be passed between jobs in the same pipeline.

That's it for today! You now know how to configure jobs to use specific runners and manage job artifacts. These are important skills for managing complex CI/CD pipelines.

In our next session, we will introduce GitLab's environment feature and how to use it to manage different deployment environments, such as staging and production. See you tomorrow!