Skip to content

Add TTL fields to Build and BuildConfig APIs #2698

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
kairosci wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Add TTL fields to Build and BuildConfig APIs #2698

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 32 additions & 0 deletions build/v1/types.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -42,6 +42,20 @@ type BuildSpec struct {
// triggeredBy describes which triggers started the most recent update to the
// build configuration and contains information about those triggers.
TriggeredBy []BuildTriggerCause `json:"triggeredBy,omitempty" protobuf:"bytes,2,rep,name=triggeredBy"`

// successfulBuildTTLSeconds defines how long (in seconds) a successful build
// is retained after completion before being automatically deleted.
// If not set, the build will not be automatically deleted.
// This mirrors the semantics of Kubernetes Job's ttlSecondsAfterFinished.
// +optional
SuccessfulBuildTTLSeconds *int32 `json:"successfulBuildTTLSeconds,omitempty" protobuf:"varint,3,opt,name=successfulBuildTTLSeconds"`

// failedBuildTTLSeconds defines how long (in seconds) a failed or errored build
// is retained after completion before being automatically deleted.
// If not set, the build will not be automatically deleted.
// This mirrors the semantics of Kubernetes Job's ttlSecondsAfterFinished.
// +optional
FailedBuildTTLSeconds *int32 `json:"failedBuildTTLSeconds,omitempty" protobuf:"varint,4,opt,name=failedBuildTTLSeconds"`
Comment on lines +46 to +58
Copy link

@qodo-code-review qodo-code-review bot Feb 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. generated.proto missing ttl fields 📘 Rule violation ✓ Correctness

• BuildSpec/BuildConfigSpec gained new TTL fields with protobuf tags, but the protobuf schema
  (generated.proto) does not include them.
• This means protobuf clients/code that rely on generated.proto/generated.pb.go will not see or
  serialize the new fields, causing API/schema drift.
• This indicates generated artifacts were not fully regenerated/synchronized prior to commit.
Agent Prompt 
## Issue description
The new TTL API fields were added to `BuildSpec`/`BuildConfigSpec` with protobuf tags, but the protobuf-generated schema/code was not updated, leaving `generated.proto` (and likely `generated.pb.go`) out of sync.

## Issue Context
This repository commits generated artifacts. When Go types change (especially with protobuf tags), the corresponding protobuf outputs must be regenerated and committed so clients and tooling remain consistent.

## Fix Focus Areas
- build/v1/types.go[46-58]
- build/v1/types.go[1012-1028]
- build/v1/generated.proto[136-161]
- build/v1/generated.proto[455-464]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment on lines +46 to +58
Copy link

@qodo-code-review qodo-code-review bot Feb 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

2. Ttl fields lack featuregate 📘 Rule violation ⛯ Reliability

• New fields were added to stable build/v1 APIs without a +openshift:enable:FeatureGate=...
  marker.
• Without feature-gating, clusters/profiles cannot control rollout of this stable API change,
  violating the repository’s stability/compatibility policy for new v1 fields.
• No corresponding FeatureGate registration for a Build TTL feature exists in features/features.go
  using the required builder pattern.
Agent Prompt 
## Issue description
The new TTL fields were added to stable `build/v1` APIs without FeatureGate markers, and there is no registered FeatureGate for this capability in `features/features.go`.

## Issue Context
Repository policy requires stable API field additions to be gated via `+openshift:enable:FeatureGate=...`, and any new FeatureGate must be registered using the builder pattern with required metadata.

## Fix Focus Areas
- build/v1/types.go[46-58]
- build/v1/types.go[1012-1028]
- features/features.go[36-90]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

}

// OptionalNodeSelector is a map that may also be left nil to distinguish between set and unset.
Expand Down Expand Up @@ -994,6 +1008,24 @@ type BuildConfigSpec struct {
// When a BuildConfig is created, the 5 most recent failed builds are retained unless this value is set.
// If removed after the BuildConfig has been created, all failed builds are retained.
FailedBuildsHistoryLimit *int32 `json:"failedBuildsHistoryLimit,omitempty" protobuf:"varint,5,opt,name=failedBuildsHistoryLimit"`

// defaultSuccessfulBuildTTLSeconds sets the default retention time (in seconds)
// for successful builds created from this BuildConfig.
// Builds created from this BuildConfig will inherit this value unless overridden
// in the Build's own successfulBuildTTLSeconds field.
// If not set, builds will not have an automatic TTL set.
// This mirrors the semantics of Kubernetes Job's ttlSecondsAfterFinished.
// +optional
DefaultSuccessfulBuildTTLSeconds *int32 `json:"defaultSuccessfulBuildTTLSeconds,omitempty" protobuf:"varint,6,opt,name=defaultSuccessfulBuildTTLSeconds"`

// defaultFailedBuildTTLSeconds sets the default retention time (in seconds)
// for failed or errored builds created from this BuildConfig.
// Builds created from this BuildConfig will inherit this value unless overridden
// in the Build's own failedBuildTTLSeconds field.
// If not set, builds will not have an automatic TTL set.
// This mirrors the semantics of Kubernetes Job's ttlSecondsAfterFinished.
// +optional
DefaultFailedBuildTTLSeconds *int32 `json:"defaultFailedBuildTTLSeconds,omitempty" protobuf:"varint,7,opt,name=defaultFailedBuildTTLSeconds"`
Comment on lines +1012 to +1028
Copy link

@qodo-code-review qodo-code-review bot Feb 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

3. No ttl integration validation tests 📘 Rule violation ⛯ Reliability

• The PR changes the build/v1 API schema but does not add integration validation tests under the
  repository’s /<group>/<version>/tests/<crd-name>/ structure.
• Without these tests, schema expectations for the new TTL fields (presence, optionality, gating
  expectations) are not enforced and regressions are more likely.
Agent Prompt 
## Issue description
API schema was extended with TTL fields but no integration validation tests were added under the expected `/<group>/<version>/tests/<crd-name>/` structure.

## Issue Context
The repository uses YAML-based integration schema tests (see `operator/v1/tests/...`). Similar tests should be added/updated to ensure the new TTL fields are validated in generated schemas and remain stable over time.

## Fix Focus Areas
- build/v1/types.go[46-58]
- build/v1/types.go[1012-1028]
- operator/v1/tests/networks.operator.openshift.io/AAA_ungated.yaml[1-20]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

}

// BuildRunPolicy defines the behaviour of how the new builds are executed
Expand Down
20 changes: 20 additions & 0 deletions build/v1/zz_generated.deepcopy.go
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

18 changes: 11 additions & 7 deletions build/v1/zz_generated.swagger_doc_generated.go
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

28 changes: 28 additions & 0 deletions openapi/generated_openapi/zz_generated.openapi.go
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.