🌱 use "preflight" in ClusterObjectSet rejection messages; add static validation e2e

[perdasilva]

Description

Two related changes for the ClusterObjectSet PreconditionsNotMet pre-apply checks:

1. Reword the condition messages: "pre-apply check" → "preflight check"

The controller's revision- and phase-level pre-apply rejection messages now say "A preflight check rejected the revision/phase: …". "Preflight" is the term users already recognize for checks that run before an operation (kubeadm, Helm, etc.), and it's the vocabulary already used in the controller's own comments, the Ready condition documentation in clusterobjectset_types.go, and the concepts docs. The condition reason (PreconditionsNotMet) is unchanged — only the human-readable message text.

Also aligned the explanatory comments in the ClusterExtension controller that describe this reason.

No CRD/reference-doc regeneration was needed: the Ready condition docstring and docs/draft/concepts/clusterobjectsets.md already used "preflight".

2. Add cos_static_validation.feature

A new e2e suite covering the revision-level (static, non-dry-run) preflight checks, which surface as Ready=False / PreconditionsNotMet:

1. Duplicate object across phases → A preflight check rejected the revision: … duplicate object found in phases: phase-a, phase-b
2. Forbidden metadata (ownerReferences baked into a manifest) → A preflight check rejected the revision: … metadata.ownerReferences: Forbidden: must be empty.

Testing

• Unit tests for the two changed controller packages pass.
• The e2e suite passes against the object-controller built from this branch (rebuilt with the new message):

2 scenarios (2 passed)
8 steps (8 passed)

Notes

• Experimental-only; tagged @BoxcutterRuntime. The feature reuses existing step definitions; no step code changes.
• Follow-up: the sibling cos_preflight.feature PR (🌱 add ClusterObjectSet pre-apply dry-run validation e2e scenarios #3027) asserts the phase-level message and must be updated to the new "preflight" wording and merged after this one.

🤖 Generated with Claude Code

Summary by CodeRabbit

• Updates
  • Validation failure messages now describe failed checks as “preflight checks” instead of “pre-apply checks.” Failure reasons and retry behavior are unchanged.
• Tests
  • Added end-to-end coverage for validation failures when the same ConfigMap appears in multiple phases or a ConfigMap manifest contains owner references. The scenarios verify that the affected revision and validation failure are reported.

[netlify]

✅ Deploy Preview for olmv1 ready!

Name	Link
🔨 Latest commit	0caedfc
🔍 Latest deploy log	https://app.netlify.com/projects/olmv1/deploys/6ad6309027f249168fba0a22
😎 Deploy Preview	https://deploy-preview-3026--olmv1.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[perdasilva]

/hold until group PR merges

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: defaults
• Review profile: CHILL
• Plan: Enterprise
• Run ID: 20552860-4a08-4775-af53-00ef0b4a5ab3

📥 Commits

Reviewing files that changed from the base of the PR and between 09abda9 and 0caedfc.

📒 Files selected for processing: 1

• test/e2e/features/cos_static_validation.feature

Included review availability: This review used your included allowance. Your plan provides up to 12 included reviews per hour; 8 remain after this review.

📝 Walkthrough

Controller validation messages and comments now use “preflight” instead of “pre-apply.” New end-to-end scenarios check PreconditionsNotMet for duplicate objects across phases and manifests with metadata.ownerReferences.

Changes: ClusterObjectSet preflight validation

Layer / File(s)	Summary
Validation outcomes and reporting internal/object-controller/controllers/clusterobjectset_controller.go, internal/operator-controller/controllers/common_controller.go, test/e2e/features/cos_static_validation.feature	Controller messages and comments use “preflight” terminology. End-to-end scenarios assert PreconditionsNotMet for a duplicate object across phases and a manifest with metadata.ownerReferences.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Other

Merge Risk: ⚪ Minimal · up to 0caed

No actionable issue is identified that should hold this change beyond normal checks.

Pre-merge checks: 5

Check name	Status	Explanation
Title check		The title is concise, specific, uses the required seedling prefix, and accurately summarizes the message update and new static-validation E2E coverage.
Description check		The description clearly explains the message changes, unchanged reason, new E2E scenarios, test results, scope, and follow-up PR. The reviewer checklist from the template is not included, but the core…
Docstring Coverage		Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 2 functions across 2 files. (1 skipped: 1 …
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: Description check

Explanation

The description clearly explains the message changes, unchanged reason, new E2E scenarios, test results, scope, and follow-up PR. The reviewer checklist from the template is not included, but the core description is complete.

Full details: Docstring Coverage

Explanation

Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 2 functions across 2 files. (1 skipped: 1 unsupported.)

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[perdasilva]

/unhold

[fao89]

/lgtm

[fgiudici]

/lgtm

[tmshort]

/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: tmshort

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [tmshort]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment