🌱 Add e2e regression test for cross-CE collision protection#2783
🌱 Add e2e regression test for cross-CE collision protection#2783perdasilva wants to merge 1 commit into
Conversation
✅ Deploy Preview for olmv1 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
There was a problem hiding this comment.
Pull request overview
Adds an end-to-end regression scenario to ensure cross-ClusterExtension “collision protection” works (a second ClusterExtension targeting an already-installed bundle cannot take over resources), and extends the godog step library to make multi-CE assertions readable and robust.
Changes:
- Adds a new e2e scenario covering duplicate ClusterExtension installs and verifies original ownership is retained.
- Extends step definitions with named ClusterExtension condition assertions, a ClusterObjectSet ownership-count assertion, and a
${PREV_NAME}template variable to reference a previously-applied CE. - Refactors message-fragment matching into a shared helper and changes template expansion to preserve unknown
${KEY}variables literally.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| test/e2e/steps/steps.go | Adds named CE steps, COS ownership-count step, ${PREV_NAME} support, message-fragment helper, and preserves unresolved template variables. |
| test/e2e/steps/hooks.go | Extends scenario context to track previousClusterExtensionName. |
| test/e2e/features/update.feature | Adds a new regression scenario validating cross-CE collision protection behavior. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
943273a to
a29cdef
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2783 +/- ##
==========================================
+ Coverage 70.42% 70.44% +0.01%
==========================================
Files 143 143
Lines 10625 10625
==========================================
+ Hits 7483 7485 +2
+ Misses 2580 2579 -1
+ Partials 562 561 -1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
a29cdef to
f79695c
Compare
f79695c to
b48aef1
Compare
b48aef1 to
cdaa226
Compare
cdaa226 to
b0c5c59
Compare
| kind: ClusterExtension | ||
| metadata: | ||
| name: ${NAME} | ||
| name: ce-orig-${SCENARIO_ID} |
There was a problem hiding this comment.
I would prefer that we keep using ${NAME} - it is a very handy way to avoid leaking how we actually craft it under the hood.
There was a problem hiding this comment.
But once you have 2 resources, how do you disambiguate?
There was a problem hiding this comment.
But once you have 2 resources, how do you disambiguate?
By name, we should track inside ScenarioContext resource kinds and their names
There was a problem hiding this comment.
The problem is we track the CE last CE name as a way to drive unnamed steps, e.g. ClusterExtension is Available. Maybe we could remove the unnamed steps, keep NAME static for the execution and let templating produce the CE name. This would require we always provide the CE name in those steps. I'm not entirely against that - I don't think it hurts readability (just makes things more precise, and anyway, if the idea if to in some sense reproduce what the user would do, every kubectl command would take the CE name anyway). Wdyt?
There was a problem hiding this comment.
I'd probably do this in a separate PR and rebase this one.
There was a problem hiding this comment.
The problem is we track the CE last CE name as a way to drive unnamed steps, e.g.
ClusterExtension is Available
such steps should work as-is if there is just single CE in the context, then it fully clear which one we are talking about.
There was a problem hiding this comment.
True, but then order becomes a dependency and the mechanics become obscure for the developer. They need to dig in to the code to understand why they can't reference a previous CE in a particular step. What do we lose by adding the additional clarity in each step?
- It doesn't impact readability and is inline with user behavior w.r.t input
- It reduces state tracking as much as a possible - simplifying each step (reducing complexity)
- Not even the extra key strokes are a concern anymore since it will all probably be generated XD
| kind: ClusterExtension | ||
| metadata: | ||
| name: ${NAME}-dup | ||
| name: ce-dup-${SCENARIO_ID} |
There was a problem hiding this comment.
same here, what is an advantage of changing it to ce-dup-${SCENARIO_ID} ?
| version: 1.0.1 | ||
| """ | ||
| Then ClusterExtension reports Progressing as True with Reason Retrying and Message includes: | ||
| Then ClusterExtension "ce-dup-${SCENARIO_ID}" reports Progressing as True with Reason Retrying and Message includes: |
There was a problem hiding this comment.
| Then ClusterExtension "ce-dup-${SCENARIO_ID}" reports Progressing as True with Reason Retrying and Message includes: | |
| Then ClusterExtension "${NAME}-dup" reports Progressing as True with Reason Retrying and Message includes: |
|
|
||
| @BoxcutterRuntime | ||
| @DeploymentConfig | ||
| Scenario: Cannot install a ClusterExtension that refers to an already installed bundle |
There was a problem hiding this comment.
given that we have the previous test, do we really need this one at all? What is the added value?
There was a problem hiding this comment.
I think the main differentiation is that in this one we ensure that when the conflicting CE has a higher revision COS it doesn't take over the resources (the regression). I think it would be ok to just merge these two since the first just checks same version collisions.
b0c5c59 to
9797be3
Compare
9797be3 to
d1a9612
Compare
- Add e2e test verifying that a second ClusterExtension targeting an
already-installed bundle cannot take over resources from the original
owner, even with a higher-revision ClusterObjectSet. The single
merged scenario covers both initial collision detection after an
upgrade and collision persistence across revisions.
- Use ${NAME} / ${NAME}-dup naming convention in the collision scenario
so CE names stay abstract. Stop overwriting sc.clusterExtensionName
in ResourceIsApplied so ${NAME} remains constant throughout a
scenario — the overwrite was always a no-op for existing tests since
they all use name: ${NAME}.
- Auto-track every applied ClusterExtension for cleanup via
addedResources in ResourceIsApplied, eliminating the manual
TrackCurrentClusterExtensionForCleanup step and the redundant
sc.clusterExtensionName cleanup in ScenarioCleanup.
- Add named CE condition steps (NamedClusterExtensionReportsCondition,
NamedClusterExtensionReportsConditionWithMessageFragment) so step
descriptions explicitly identify which CE is being asserted.
- Add ClusterExtensionOwnsClusterObjectSets step to verify the number
of ClusterObjectSets owned by a named CE.
- Extract messageFragmentComparison helper to deduplicate the
fragment-matching closure across condition steps.
- Preserve unresolved template variables as literal ${KEY} instead of
silently substituting empty string.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Per G. da Silva <pegoncal@redhat.com>
d1a9612 to
430c5d6
Compare
Summary
${NAME}/${NAME}-dupnaming convention in the collision scenario so CE names stay abstract. Stop overwritingsc.clusterExtensionNameinResourceIsAppliedso${NAME}remains constant throughout a scenario — the overwrite was always a no-op for existing tests since they all usename: ${NAME}.addedResourcesinResourceIsApplied, eliminating the manualTrackCurrentClusterExtensionForCleanupstep and the redundantsc.clusterExtensionNamecleanup inScenarioCleanup.NamedClusterExtensionReportsCondition,NamedClusterExtensionReportsConditionWithMessageFragment) so step descriptions explicitly identify which CE is being asserted.ClusterExtensionOwnsClusterObjectSetsstep to verify the number of ClusterObjectSets owned by a named CE.messageFragmentComparisonhelper to deduplicate the fragment-matching closure across condition steps.${KEY}instead of silently substituting empty string.Note: ClusterObjectSets still use the legacy
sc.clusterObjectSetNamecleanup path rather thanaddedResourcestracking. The same consolidation can be done in a follow-up.Test plan
go vetpasses🤖 Generated with Claude Code