You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Addresses OPRUN-4795 with two focused, standalone-compatible ClusterObjectDeployment progress-deadline scenarios:
Recovery before expiry: hold revision ${NAME}-1 unready using a ConfigMap data-key probe, verify completion is absent, release the gate, and verify completion before its server-assigned creation timestamp plus the configured one-minute deadline, with exactly one owned revision.
Post-completion health regression: regress the managed ConfigMap after completion and observe it for 70 seconds. COS readiness and COD availability must reflect the regression while completedAt remains present and COD Progressing=False/NewClusterObjectSetProgressed persists beyond the deadline. Restore readiness and verify completion remains present and health recovers without another revision.
The data.ready gate is intentionally omitted from the managed manifest and changed through the existing resource is applied step, avoiding image pulls, COD template changes, and a deadline-specific gate step. Existing ownership/count, resource-match, and condition steps express the endpoint assertions. New helpers only check completion presence, compare completion with the configured deadline, and observe completion presence/the expected named and numbered revision/ownership/current health together throughout the unhealthy window. No completion snapshots, remembered UIDs, or incomplete/completed state machine are added. Timestamp immutability/removal are already covered by API validation tests; detecting delete/recreate under the same revision name is outside this E2E's scope. Regression coverage includes deadline boundaries, missing completion timestamps, wrong/extra/foreign revisions, stale conditions, and failures after an initially successful observation.
Both scenarios live in cod_progress_deadline.feature and are selectable with @CODDeadlineLifecycle. Existing Secret-precondition and other feature scenarios are unchanged. No runtime, API/schema, dependency, Makefile, or CI workflow changes are included. The current COD schema already supports a one-minute deadline, so no CRD relaxation is needed. Restart coverage and creation-failure injection remain out of scope.
Validation
Passed locally:
make test-unit (including race detection; rerun before publishing)
make lint (custom vet plus golangci-lint; zero issues; rerun before publishing)
go test -count=1 -race -tags=containers_image_openpgp ./test/internal/e2e/...
Focused new helper regressions repeated three times under race detection
All four component suite compilations and the legacy E2E entry-point compilation
Component and legacy registration with @CODDeadlineLifecycle: 2 scenarios / 38 steps, all resolved; execution was skipped, so this is registration evidence only
Real envtest API-server validation: both actual COD fixture manifests accepted by the current CRDs; the existing kubectl apply -f - path changes data.ready true/false/true and each value survives repeated SSA of the original managed manifest, preserving UID, payload, and labels
Whitespace and four-file scope checks
Live deployed-controller E2E was not run locally. Docker is stopped, and the saved experimental cluster endpoint (127.0.0.1:49806) refuses connections. The envtest schema/SSA checks above do not establish a deployed-controller rollout pass. Experimental E2E CI must validate the two new scenarios.
Focused live command once an integrated experimental installation is available:
KUBECONFIG=.kubeconfig/operator-controller-experimental-e2e.kubeconfig \
go test -count=1 -v -tags=containers_image_openpgp ./test/e2e/object-controller/... \
-args --godog.tags='@CODDeadlineLifecycle'
For an isolated object-controller installation, additionally pass --e2e.object-controller-only; do not pass that flag against the integrated installation.
Reviewer Checklist
API Go Documentation (not applicable: no API changes)
Tests: Unit Tests (and E2E Tests, if appropriate)
Comprehensive Commit Messages
Links to related GitHub Issue(s)
Summary by CodeRabbit
Tests
Added end-to-end coverage for deployment progress deadlines, including revisions that complete before their deadline and remain completed through a temporary health issue.
Added checks for readiness, availability, progression, and completion timing when a key-gated revision is allowed to proceed.
This pull-request has been approved by: Once this PR has been reviewed and has the lgtm label, please assign tmshort for approval. For more information see the Code Review Process.
The full list of commands accepted by this bot can be found here.
Details
Needs approval from an approver in each of these files:
No actionable comments were generated in the recent review.
Walkthrough
Adds E2E helpers, tests, and scenarios for ClusterObjectDeployment progress deadlines. The checks cover completion before the original deadline and retention of a completed revision during health regression and recovery.
Changes: Deadline lifecycle checks
Layer / File(s)
Summary
Completion and deadline checks test/internal/e2e/object-controller/steps/deadline_steps.go, test/internal/e2e/object-controller/steps/deadline_steps_test.go, test/internal/e2e/object-controller/steps/steps.go
Adds steps to check for a completion timestamp and verify completion before the deployment’s progress deadline. Tests cover timestamp boundaries, missing data, lookup errors, and invalid JSON. Registers the new steps.
Completed revision during health regression test/internal/e2e/object-controller/steps/deadline_steps.go, test/internal/e2e/object-controller/steps/deadline_steps_test.go
Adds polling checks for revision identity, ownership, completion, and unhealthy conditions over a specified duration. Tests cover invalid states, API errors, cancellation, and duration validation.
Adds scenarios that check completion before the original deadline and that a completed revision remains the sole revision during health regression and recovery.
This PR only adds test coverage for the ClusterObjectDeployment progress-deadline lifecycle and does not change runtime behavior. No actionable merge-blocking issue was found. The new scenarios still need to pass in the experimental E2E CI run.
Pre-merge checks: 4
Check name
Status
Explanation
Title check
The title names the OPRUN-4795 ticket and says the PR covers the ClusterObjectDeployment progress-deadline lifecycle. The changeset adds two COD progress-deadline E2E scenarios in cod_progress_deadlin…
Description check
The description follows the template. It has a Description section that explains the two scenarios, the motivation, and the scope. It has a Validation section that lists the local checks and states th…
Linked Issues check
Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check
Check skipped because no linked issues were found for this pull request.
Full details: Title check
Explanation
The title names the OPRUN-4795 ticket and says the PR covers the ClusterObjectDeployment progress-deadline lifecycle. The changeset adds two COD progress-deadline E2E scenarios in cod_progress_deadline.feature, plus steps and helpers that support them. The title matches the main change. It uses the seedling icon that the template asks for. It does not cover the detail of the two scenarios, which is acceptable.
Full details: Description check
Explanation
The description follows the template. It has a Description section that explains the two scenarios, the motivation, and the scope. It has a Validation section that lists the local checks and states that live E2E was not run. It keeps the Reviewer Checklist. The checklist items are unchecked, but the template does not require them to be checked before merge. The description does not link a GitHub issue directly, but it links the OPRUN-4795 Jira ticket.
Finishing Touches
Generate unit tests (beta)
Commit to this branch
Create a new PR
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Recent review info
Run configuration
Source mode: Auto
Repository: Unavailable
Branch: Unavailable
File: No configuration file from this repository applied
Commit: Unavailable
Layers: defaults
Review profile: CHILL
Plan: Enterprise
Run ID: 8b343b5a-9352-4559-9bcd-57195d2a60fa
Commits
Reviewing files that changed from the base of the PR and between 9cad994 and 85cf989.
Included review availability: This review used your included allowance. Your plan provides up to 12 included reviews per hour; 10 remain after this review.
Add dedicated ConfigMap-key-gated deadline scenarios for recovery before the original deadline and health regression after successful completion. Verify revision identity, ownership, current-generation status, and durable completion throughout a post-deadline observation window.
Keep readiness control outside the managed manifest so gate changes neither create revisions nor conflict with reconciliation. Add focused helper regressions without changing the existing Secret-precondition scenarios or runtime behavior.
Addresses OPRUN-4795.
Signed-off-by: Per G. da Silva <pegoncal@redhat.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Addresses OPRUN-4795 with two focused, standalone-compatible ClusterObjectDeployment progress-deadline scenarios:
${NAME}-1unready using a ConfigMap data-key probe, verify completion is absent, release the gate, and verify completion before its server-assigned creation timestamp plus the configured one-minute deadline, with exactly one owned revision.completedAtremains present and CODProgressing=False/NewClusterObjectSetProgressedpersists beyond the deadline. Restore readiness and verify completion remains present and health recovers without another revision.The
data.readygate is intentionally omitted from the managed manifest and changed through the existingresource is appliedstep, avoiding image pulls, COD template changes, and a deadline-specific gate step. Existing ownership/count, resource-match, and condition steps express the endpoint assertions. New helpers only check completion presence, compare completion with the configured deadline, and observe completion presence/the expected named and numbered revision/ownership/current health together throughout the unhealthy window. No completion snapshots, remembered UIDs, or incomplete/completed state machine are added. Timestamp immutability/removal are already covered by API validation tests; detecting delete/recreate under the same revision name is outside this E2E's scope. Regression coverage includes deadline boundaries, missing completion timestamps, wrong/extra/foreign revisions, stale conditions, and failures after an initially successful observation.Both scenarios live in
cod_progress_deadline.featureand are selectable with@CODDeadlineLifecycle. Existing Secret-precondition and other feature scenarios are unchanged. No runtime, API/schema, dependency, Makefile, or CI workflow changes are included. The current COD schema already supports a one-minute deadline, so no CRD relaxation is needed. Restart coverage and creation-failure injection remain out of scope.Validation
Passed locally:
make test-unit(including race detection; rerun before publishing)make lint(custom vet plus golangci-lint; zero issues; rerun before publishing)go test -count=1 -race -tags=containers_image_openpgp ./test/internal/e2e/...@CODDeadlineLifecycle: 2 scenarios / 38 steps, all resolved; execution was skipped, so this is registration evidence onlykubectl apply -f -path changesdata.readytrue/false/true and each value survives repeated SSA of the original managed manifest, preserving UID, payload, and labelsLive deployed-controller E2E was not run locally. Docker is stopped, and the saved experimental cluster endpoint (
127.0.0.1:49806) refuses connections. The envtest schema/SSA checks above do not establish a deployed-controller rollout pass. Experimental E2E CI must validate the two new scenarios.Focused live command once an integrated experimental installation is available:
For an isolated object-controller installation, additionally pass
--e2e.object-controller-only; do not pass that flag against the integrated installation.Reviewer Checklist
Summary by CodeRabbit