With a recent upgrade to GitLab runner software, we are now able to support Flux directly for CI pipelines running on Flux-enabled clusters. This bulletin describes the changes that will occur when this feature is enabled.

On 6/1/2023, the meaning of the "batch" tag will change from today's meaning of "Slurm wrappers" to "Flux executor" on Flux-enabled clusters. If you are  currently selecting runners based solely on the "batch" tag on a Flux-enabled cluster, your jobs will break since the GitLab runner will switch from using  Slurm wrappers to using Flux directly. If you are using the slurm tag, your jobs will continue to run as they previously did with no intervention required on your part.

As of this writing, Flux-enabled clusters are: corona, tenaya, tioga, rzalastor, rzvernal

GitLab Runner Tags and their Meanings on Flux-Enabled Clusters

 

Tag

Current Meaning

New Meaning (as of 6/1/2023)

batch

Slurm wrappers

Flux executor

batch-secondary

n/a

Slurm wrappers or slurm executor, if cluster is running both Flux and Slurm

flux

n/a

Flux executor

slurm

Slurm executor or slurm wrappers

Slurm executor or slurm wrappers

shell

Shell on a login node

Shell on a login node

 

NOTE The "batch" tag will continue to mean "Slurm executor" on clusters that only support Slurm, and "LSF executor" on clusters that only support LSF.

Selection of Runners (as of 6/1/2023)

Desired Effect

Tag Selection

Run on a cluster's primary scheduler

batch

Run on a cluster's secondary scheduler

batch-secondary

Run on flux specifically

flux

Run on slurm (or wrappers) specifically

slurm

Run on LSF specifically

lsf

Run on a login node

shell