gitlab-runner v19.2.2 released: review CRD and behaviour

[github-actions]

Upstream released v19.2.2; DefaultRunnerImage pins v19.1.0.

• Release notes
• CHANGELOG
• Runner image: gitlab/gitlab-runner:alpine-v19.2.2

Executor config

Upstream executor toml keys, v19.1.0 to v19.2.2:

No keys added upstream

No new CRD fields needed for the executor config.

In upstream v19.2.2 but not exposed by api/v1beta2/gitlab_types.go

• allowed_groups
• allowed_users
• app_armor_profile
• automount_service_account_token
• autoscaler
• cleanup_resources_timeout
• environment
• idle_count
• idle_time
• localhost_profile
• match_label_keys
• max_pause_pods
• mismatch_label_keys
• mount_propagation
• nfs
• pause_pod_image
• pause_pod_image_pull_secrets
• pause_pod_priority_class_name
• periods
• pod_disruption_budget
• policy
• preemptive_mode
• print_pod_warning_events
• proc_mount
• retry_backoff_max
• retry_limit
• retry_limits
• scale_factor
• scale_factor_limit
• seccomp_profile
• selinux_type
• server
• size_limit
• timezone
• type
• use_service_account_image_pull_secrets

Helper image

Helper image published for v19.2.2 (65 tags). Linux flavours:

• (default)
• alpine-edge
• alpine-latest
• alpine3.21
• concrete
• ubi-fips
• ubuntu

helper_image_flavor describes itself as "(alpine, ubuntu)", which omits:

• alpine-edge
• alpine-latest
• concrete
• ubi-fips

Before closing

• Decide whether any added key needs a CRD field in api/v1beta2.
• Check the release notes for behaviour changes the reconciler assumes.
• Bump DefaultRunnerImage and let e2e exercise the new runner.

[alekc]

Done in #73, merged as 01c1a4c. Answering the checklist rather than closing silently, because two of the answers are not what the generated body above implies.

Does any added key need a CRD field? No, but "No keys added upstream" is narrower than it reads. hack/runner-release-watch.sh seeds its walk from structs matching ^Kubernetes, so that line means "none in the Kubernetes executor subtree" and cannot speak for the rest of the release. Diffing every toml key in upstream common/config.go gives 408 at v19.1.0 against 424 at v19.2.2: 16 new names, 23 (struct, key) pairs, zero removed, all under experimental.boot_verify and experimental.usage_logger. Checked by hand, every one is opt-in and none changes a default, so nothing needs exposing yet. The misleading heading is filed as #76.

For the record, the "not exposed" list above was already stale by the time this was picked up: 23 of those 36 keys had been exposed by #66, and the remaining 13 are the autoscaler subtree, deliberately unexposed and suppressed since #70. The helper_image_flavor complaint was fixed by #71, and the one key the old one-directional watcher could not see was handled in #72.

Behaviour changes the reconciler assumes? None that affect the reconciler, two that reach users. Both are in 01c1a4c's commit body, which is where they need to be because there is no changelog: block in .goreleaser.yaml and no CHANGELOG.md, so the commit body is the release note. The helper image moves with the runner, since the runner derives its helper tag from its own version, so build pods now pull gitlab-runner-helper:<arch>-v19.2.2; mirrored and air-gapped registries need the new tag or a pinned helper_image. And Kubernetes config plus secret-resolution failures now report configuration_error where upstream reported runner_system_failure, which silently stops retry: when: [runner_system_failure] from firing.

v19.2.0 also added a /health/ready endpoint, not adopted as the readiness probe. It is gated on boot-verify, which is opt-in and never enabled by this operator, so it returns 200 as soon as the listener binds and carries no more information than the current TCP check on 9090. It only becomes a better signal alongside exposing experimental.boot_verify, and the path 404s before v19.2.0 while spec.image is user-overridable, so it cannot be switched unconditionally. Filed as #75.

Did e2e exercise the new runner? Yes, with no e2e change needed. No Runner or MultiRunner spec in test/e2e/e2e_test.go sets an image, so the suite ran v19.2.2 through the Kubernetes executor on four Kubernetes versions, which is also what proved the new helper tag pulls.

Superseded by #74 for v19.3.0.