Skip to content

🐛 Add bundle-version and package-name annotations to CER phase objects - #2580

Merged
openshift-merge-bot[bot] merged 2 commits into
operator-framework:mainfrom
pedjak:OCPBUGS-78311/fix-cer-version-status
Mar 25, 2026
Merged

🐛 Add bundle-version and package-name annotations to CER phase objects#2580
openshift-merge-bot[bot] merged 2 commits into
operator-framework:mainfrom
pedjak:OCPBUGS-78311/fix-cer-version-status

Conversation

@pedjak

@pedjakpedjak commented Mar 20, 2026

Copy link
Copy Markdown
Contributor

Description

When upgrading between bundle versions that produce identical Kubernetes
manifests, the installed version status was not updated because CER phases
were identical across versions, causing in-place patches instead of new
revision creation.

Propagate bundle-version and package-name annotations onto each rendered
object within CER phases so that different bundle versions always produce
distinct phases, triggering new revision creation via phase immutability.
As a side benefit, every applied bundle resource now carries two annotations
that immediately tell an observer which package and version it belongs to.

Changes

  • Propagate bundle-version and package-name annotations onto each rendered object within CER phases
  • Add e2e test catalog entry with identical bundle content at a different version (1.0.4)
  • Add e2e scenario verifying that upgrading between versions with identical manifests creates a new revision
  • Rename mergeLabelMaps to mergeStringMaps (now used for both labels and annotations)

Reviewer Checklist

  • API Go Documentation
  • Tests: Unit Tests (and E2E Tests, if appropriate)
  • Comprehensive Commit Messages
  • Links to related GitHub Issue(s)

When upgrading between bundle versions that produce identical Kubernetes
manifests, the installed version status was not updated because CER phases
were identical across versions, causing in-place patches instead of new
revision creation.
Propagate bundle-version and package-name annotations onto each rendered
object within CER phases so that different bundle versions always produce
distinct phases, triggering new revision creation via phase immutability.
As a side benefit, every applied bundle resource now carries two annotations
that immediately tell an observer which package and version it belongs to.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
CopilotAI review requested due to automatic review settings March 20, 2026 13:56
@netlify

netlifyBot commented Mar 20, 2026

Copy link
Copy Markdown

Deploy Preview for olmv1 ready!

NameLink
🔨 Latest commitb18a28b
🔍 Latest deploy loghttps://app.netlify.com/projects/olmv1/deploys/69c404e63b165e00087b99a4
😎 Deploy Previewhttps://deploy-preview-2580--olmv1.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

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

CopilotAI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Pull request overview

Propagates bundle metadata (package name + bundle version) onto each rendered object in ClusterExtensionRevision (CER) phases so that otherwise-identical manifests across bundle versions still produce distinct phases and trigger new revision creation (fixing installed version status not updating on upgrade).

Changes:

  • Add a new test bundle version (1.0.4) that reuses the exact same bundle image as 1.0.0 to reproduce the “identical manifests across versions” upgrade case.
  • Add an E2E update scenario that upgrades from 1.0.0 to 1.0.4.
  • Update revision generation to stamp olm.operatorframework.io/bundle-version and olm.operatorframework.io/package-name as annotations on each rendered object, with unit test updates.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.

FileDescription
testdata/images/catalogs/test-catalog/v1/configs/catalog.yamlAdds a new bundle version (1.0.4) that points at the same image as 1.0.0 for regression testing identical renders across versions.
test/e2e/features/update.featureAdds an E2E scenario upgrading to 1.0.4 to validate upgrade behavior when bundle content is identical.
internal/operator-controller/applier/boxcutter_test.goUpdates unit test expectations to include the new per-object annotations.
internal/operator-controller/applier/boxcutter.goImplements propagation of bundle-version/package-name annotations onto each rendered object (Helm and non-Helm paths).

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment threadinternal/operator-controller/applier/boxcutter.go Outdated
Comment threadinternal/operator-controller/applier/boxcutter.go Outdated
Comment threadinternal/operator-controller/applier/boxcutter.go Outdated
Comment threadtest/e2e/features/update.feature
Comment threadinternal/operator-controller/applier/boxcutter_test.go
@pedjak
pedjak requested review from camilamacedo86, dtfranz and perdasilva and removed request for grokspawnMarch 20, 2026 14:16
@codecov

codecovBot commented Mar 20, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 67.84%. Comparing base (0db26d7) to head (e18ab88).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files
@@ Coverage Diff @@## main #2580 +/- ##
==========================================
+ Coverage 67.74% 67.84% +0.10% 
==========================================
Files 137 137 Lines 9560 9591 +31 ==========================================
+ Hits 6476 6507 +31 
Misses 2585 2585 Partials 499 499 
FlagCoverage Δ
e2e38.15% <10.00%> (-0.02%)⬇️
experimental-e2e51.27% <65.00%> (+0.20%)⬆️
unit52.90% <92.50%> (+0.10%)⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Comment threadinternal/operator-controller/applier/boxcutter.go
@joelanford

Copy link
Copy Markdown
Member

cc @grokspawn Should we be officially plumbing "release" everywhere that we plumb "version" now?

@grokspawn

grokspawn commented Mar 20, 2026

Copy link
Copy Markdown
Contributor

I think ideally we would think in terms of CompositeVersion. I'll take a look later.
We should also be able to rely on uniqueness from Bundle.VersionString or variations.

- Rename mergeLabelMaps to mergeStringMaps since it handles both labels and annotations
- Only set bundle-version/package-name annotations when values are non-empty
- Update unit test to use realistic revisionAnnotations values
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@pedjakpedjak changed the title 🐛 Add bundle-version and package-name annotations to CER phase objects🐛 Add bundle-version, package-name, and bundle-release annotations to CER phase objectsMar 24, 2026

CopilotAI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Pull request overview

Copilot reviewed 12 out of 12 changed files in this pull request and generated 1 comment.


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment threadinternal/operator-controller/labels/labels.go Outdated

@camilamacedo86camilamacedo86 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I am OK with the proposal.
/lgtm

@openshift-ciopenshift-ciBot added the lgtm Indicates that a PR is ready to be merged. label Mar 24, 2026
@tmshort

Copy link
Copy Markdown
Contributor

/hold
@grokspawn were there additional changes to be made here?

@openshift-ciopenshift-ciBot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Mar 24, 2026
@tmshort

Copy link
Copy Markdown
Contributor

/approve
@pedjak remove the hold if you get a response from @grokspawn

@openshift-ciopenshift-ciBot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Mar 24, 2026

@joelanfordjoelanford left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Quick review of the implementation. All looks good to me except the one comment about putting Version and Release together in the BundleMetadata API/struct.

Will try to find time to review tests today if you need me to.

Can you review the Copilot reviews and address/resolve?

type RevisionMetadata struct {
RevisionName string
Package string
Release string

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Do we need to put this in the BundleMetadata? Seems like it is something that is a very close sibling of Version.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

Do we need to put this in the BundleMetadata? Seems like it is something that is a very close sibling of Version.

My understanding from
#2580 (comment)
is that we want to have it, so that we can propagate it on each of applied resources. If not, we can remove it.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I left a similar comment in my review. I feel that we will need to have another pass through this flow when we have consolidated the bundle version types down to a single one. At that point, I'd prefer to see that type consistently used with the exception of the clusterextension API itself (where we probably cannot adjust since it's GA).
But I didn't think we had to have it now. Once we merge operator-framework/operator-registry#1938 I think that we can adjust those types.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

Do we need to put this in the BundleMetadata? Seems like it is something that is a very close sibling of Version.

After double checking not sure if we can - if add it to BundleMetadata this will also API/CRD change and that part of API is already GA. Let's keep it where it is for now until operator-framework/operator-registry#1938 merged or we address it in that PR.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Perhaps we should hold off on release plumbing in this PR then? And then @grokspawn will cover "plumb release everywhere that version already is plumbed" as its own effort?


type Release []bsemver.PRVersion

// String returns the dot-separated string representation of the release segments.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

We'll be pivoting away from this type to an equivalent type in op-reg, but they behave exactly the same so we don't have to do it right this minute.

}
}

func TestRelease_String(t *testing.T) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I initially was going to ask for add'l testing to align this properly with its origin, but this can come when we adopt the op-reg type.

Image: resolvedBundle.Image,
// TODO: Right now, operator-controller only supports registry+v1 bundles and has no concept
// of a "release" field. If/when we add a release field concept or a new bundle format
// we need to re-evaluate use of `AsLegacyRegistryV1Version` so that we avoid propagating

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think we need to have a larger conversation about the callflow here, but I think it's probably better to wait until we merge operator-framework/operator-registry#1938 and get the type adoption changes made. I was initially going to ask for changes here, but since this is more mature than that I think we can defer.

@grokspawn

Copy link
Copy Markdown
Contributor

@joelanford I'm good with this effort. I'll let you release the hold when you have completed review.

@pedjak
pedjakforce-pushed the OCPBUGS-78311/fix-cer-version-status branch from e18ab88 to b18a28bCompareMarch 25, 2026 15:53
@openshift-ciopenshift-ciBot removed the lgtm Indicates that a PR is ready to be merged. label Mar 25, 2026
@pedjakpedjak changed the title 🐛 Add bundle-version, package-name, and bundle-release annotations to CER phase objects🐛 Add bundle-version and package-name annotations to CER phase objectsMar 25, 2026
@pedjak

Copy link
Copy Markdown
ContributorAuthor

@grokspawn@joelanford revert the last commit, ptal

@joelanfordjoelanford left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

/approve

@openshift-ciopenshift-ciBot added the lgtm Indicates that a PR is ready to be merged. label Mar 25, 2026
@openshift-ci

Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: joelanford, 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:

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

@joelanford

Copy link
Copy Markdown
Member

/hold cancel

@openshift-ciopenshift-ciBot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Mar 25, 2026
@openshift-merge-bot
openshift-merge-botBot merged commit d57c077 into operator-framework:mainMar 25, 2026
46 checks passed
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approvedIndicates a PR has been approved by an approver from all required OWNERS files.lgtmIndicates that a PR is ready to be merged.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants

@pedjak@joelanford@grokspawn@tmshort@camilamacedo86