Pipelines as Code 0.51 adds bounded provider retries and a credential-host boundary
The upstream release gives administrators opt-in recovery from short GitHub and GitLab failures while restricting where GitHub credentials may be sent.
Pipelines as Code 0.51.0 changes two failure boundaries in Git-driven CI: how long the controller tolerates a temporarily unavailable provider, and which provider hosts are allowed to receive GitHub credentials. The release shipped September 10 with upstream OpenShift and Kubernetes installation manifests.
Retries are deliberately opt-in
The new provider retry path is disabled by default. Administrators enable it with enable-api-retry; the initial request counts toward the default limit of four attempts, and the default maximum delay between attempts is 120 seconds. GitHub and GitLab requests then use backoff with jitter for rate limits, temporary server errors and selected network failures.
That is recovery for a short disturbance, not durable queueing. If a provider asks the controller to wait longer than the configured ceiling, Pipelines as Code stops rather than holding webhook processing indefinitely. After the attempts are exhausted, the original provider error follows the existing logs, events and status path. The implementation notes also exclude operations whose repetition could create duplicate comments, statuses or other mutations after an uncertain failure.
The practical effect is narrower than “retry everything,” and that is useful. Teams can absorb a brief rate-limit window or provider outage without turning a webhook handler into an unbounded backlog.
Credentials get an administrator-owned boundary
Version 0.51 also adds trusted-provider-hostnames, a controller ConfigMap allowlist intended to stop a crafted webhook or Repository resource from redirecting inherited GitHub credentials to an attacker-selected endpoint. Validation happens before token minting and client creation, according to the security change.
With the list empty, known public services remain trusted, publicly routable self-hosted hosts can be learned only from provider-authenticated webhooks, and private, loopback, link-local and in-cluster hosts are not learned automatically. Once an administrator supplies a non-empty list, it becomes authoritative—including for public services—and automatic learning stops. Incoming webhook paths without a provider signature require explicit configuration for a self-hosted host.
The release notes say the allowlist currently gates the GitHub provider; the other providers are still being moved onto it. Operators should not read the new key as universal provider isolation yet.
What OpenShift Pipelines teams should do
Red Hat documents Pipelines as Code as part of OpenShift Pipelines. Teams should first determine which Pipelines as Code build their Operator channel supplies rather than applying the upstream manifest over an Operator-managed installation.
When a supported build carrying these changes arrives, administrators should inventory every GitHub Enterprise hostname and every unsigned incoming-webhook route before setting a non-empty allowlist. A partial list can intentionally block public SaaS, but it can also interrupt legitimate traffic. Retry settings should start at their bounded defaults and be monitored; they improve resilience to short provider faults, but they do not replace pipeline admission controls or a persistent event queue.
sources
- Pipelines as Code v0.51.0 release notesgithub.com
- Provider API retry implementationgithub.com
- Trusted provider hostname implementationgithub.com
- Red Hat OpenShift Pipelines 1.22 documentationdocs.redhat.com
comments · 0