Using GitLab Runner for multi-platform build and test processes
TypeScriptTo use a GitLab Runner for multi-platform build and test processes with Pulumi, you'll first need to define a GitLab Runner resource. GitLab Runners are a powerful feature of GitLab that allow you to run jobs and deploy apps to different environments and different scenarios according to your development needs.
Here's a high-level overview of the steps you'll take with the Pulumi TypeScript program:
- Initialize a new project: Set up a new Pulumi project and prepare it for use with the GitLab provider.
- Provision a GitLab Runner: Define a
gitlab.Runner
resource which will represent a runner capable of multi-platform builds. - Configure the Runner: Set properties such as
tagLists
,locked
, andpaused
to ensure that the runner behaves as expected within your CI/CD workflows.
Below is a simple program written in TypeScript to provision a GitLab Runner using Pulumi. This program assumes you have the necessary GitLab registration token that will be used to register the runner with your GitLab instance.
import * as pulumi from "@pulumi/pulumi"; import * as gitlab from "@pulumi/gitlab"; // Construct a new GitLab runner const multiPlatformRunner = new gitlab.Runner("multiPlatformRunner", { locked: false, paused: false, tagList: ["docker", "linux", "windows", "mac"], // Specify platform tags for targeting specific builds accessLevel: "ref_protected", description: "Multi-platform runner", runUntagged: false, maximumTimeout: 3600, // A registrationToken is needed to register a runner with the GitLab instance // IMPORTANT: Treat registration tokens like a password and keep them secret registrationToken: pulumi.secret("YOUR_GITLAB_REGISTRATION_TOKEN"), // Replace with your GitLab registration token }); // The registration token is a sensitive value and shouldn't be directly exposed // The runner ID can be exported to reference the runner elsewhere if needed. export const runnerId = multiPlatformRunner.id;
Remember to replace
YOUR_GITLAB_REGISTRATION_TOKEN
with your actual GitLab registration token.Explanation:
-
gitlab.Runner: This resource represents a GitLab Runner and it is equivalent to registering a runner in GitLab.
-
locked: If set to
true
, this runner will be available only for the projects explicitly listed in it. -
paused: If set to
true
, the runner will not process jobs unless manually unpaused. -
tagList: Tags are important for the GitLab CI/CD because they determine which jobs the runner can handle.
-
accessLevel: Defines the runner access level.
ref_protected
means the runner will only take jobs from protected branches or tags. -
description: A brief note about the runner to describe its intended use or capabilities.
-
runUntagged: Set to
false
to make sure this runner will not be used for jobs without tags. -
maximumTimeout: Defines the maximum timeout set for jobs handled by this Runner.
-
registrationToken: The registration token is used to securely register the runner with your GitLab instance. It should be kept secret.
Next Steps:
After deploying this Pulumi program, the GitLab Runner should be registered in your GitLab instance. To automate and manage builds and tests across multiple platforms, you would define CI/CD jobs within your
.gitlab-ci.yml
file in your repositories. You would use the tags specified with each job to instruct GitLab which runner to use for each job. For instance, if you have a job that requires a Windows environment, you would tag that job withwindows
, and the runner with thewindows
tag will pick up and execute the job.You should also adjust your GitLab runner's configuration to target the specific platforms and adjust the concurrent and check interval settings according to your needs. It's worth noting that managing the underlying infrastructure where the GitLab Runner will be hosted, such as VMs or Kubernetes clusters, would require additional resources and is beyond the scope of the basic GitLab Runner registration shown here.