Skip to main content

GitLab Runner

The GitLabRunner is a read-only resource that provides status information about the claimed GitLab runner. While the GitLabRunnerClaim is used to request and set up a runner, the GitLabRunner reflects the current operational state of that runner within the system.

This clear distinction is essential to identify and understand potential runtime issues. For instance:

  • The runner's authentication token might be revoked or its permissions altered.
  • The connected GitLab instance's API could face interruptions or outages.
  • An update to the GitLab instance might introduce changes that affect the runner's operations.

By monitoring the status section of GitLabRunner resource, you can gain insights into these operational challenges and take appropriate action to ensure consistent pipeline job execution.

The metadata section is used to uniquely identify objects and to provide other information that is not directly tied to a resource's configuration.

Namespace defines the space within which each GitLabRunner name must be unique.

Each GitLabRunner name must be unique, within a namespace. The name must contain only lower-case letters, digits and dashes.

In this section, we've described only two fields that are necessary and sufficient for users on Puzl. For a more in-depth explanation of metadata and its various fields, refer to the official Kubernetes documentation.

The section defines the desired state of the object. It describes the characteristics you want the resource to have: its configuration, settings, and data.

Name of the GitLabRunnerClaim resource initiated this GitLabRunner resource creation.

Internal system reference to the applied service manifest.

Internal system reference to the runner release.

The section provides information about the current state of the object. It is populated by the platform and is used to inform users about the state of the resource, whether it's currently operational, and additional metadata like timestamps.


Represents the high-level summary of the current status of the resource.

Conditions are designed based on Kubernetes API conventions. Conditions represent the logical states that the resource has passed through.


The last time the condition transitioned from one status to another.


The value of metadata.generation when the condition has been transited last time.


A human-readable message indicating details about the transition.


A one-word, CamelCase reason caused the transition of the resource to this condition.


The current status of the condition. Can be one of: True, False, or Unknown.


Unique type of the resource condition.