Skip to content

🌱 Add enum validation annotation to CollisionProtection - #2334

Merged
openshift-merge-bot[bot] merged 1 commit into
operator-framework:mainfrom
perdasilva:revision-api-fixes
Nov 17, 2025
Merged

🌱 Add enum validation annotation to CollisionProtection#2334
openshift-merge-bot[bot] merged 1 commit into
operator-framework:mainfrom
perdasilva:revision-api-fixes

Conversation

@perdasilva

@perdasilvaperdasilva commented Nov 14, 2025

Copy link
Copy Markdown
Contributor

Description

Adds missing enum validation on CollisionProtection +kubebuilder:validation:Enum=Prevent;IfNoController;None

Reviewer Checklist

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

@perdasilva
perdasilva requested a review from a team as a code ownerNovember 14, 2025 16:09
CopilotAI review requested due to automatic review settings November 14, 2025 16:09
@netlify

netlifyBot commented Nov 14, 2025

Copy link
Copy Markdown

Deploy Preview for olmv1 ready!

NameLink
🔨 Latest commit325050f
🔍 Latest deploy loghttps://app.netlify.com/projects/olmv1/deploys/691afac61ab1ef0008077863
😎 Deploy Previewhttps://deploy-preview-2334--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

This PR fixes three small issues discovered during an automatic review of the ClusterExtensionRevision API: corrects a typo in the kubebuilder validation annotation for the Revision field's minimum value, adds missing enum validation to the CollisionProtection field, and changes the Revision field type from int64 to int32.

  • Fixed typo in kubebuilder validation annotation (Minimum:=1Minimum=1)
  • Added enum validation to CollisionProtection field
  • Changed Revision field type from int64 to int32

Reviewed Changes

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

FileDescription
api/v1/clusterextensionrevision_types.goFixed validation typo, added CollisionProtection enum validation, and changed Revision field from int64 to int32
manifests/experimental.yamlUpdated generated CRD manifest with CollisionProtection enum values and int32 format for Revision
manifests/experimental-e2e.yamlUpdated generated e2e CRD manifest with CollisionProtection enum values and int32 format for Revision
helm/olmv1/base/operator-controller/crd/experimental/olm.operatorframework.io_clusterextensionrevisions.yamlUpdated generated Helm CRD manifest with CollisionProtection enum values and int32 format for Revision

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

@pedjakpedjak 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.

It looks that this PR could be reduced to the validation of CollisionProtection field only.

// +kubebuilder:validation:Minimum=1
// +kubebuilder:validation:XValidation:rule="self == oldSelf", message="revision is immutable"
Revision int64 `json:"revision"`
Revision int32 `json:"revision"`

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.

what we are improving/fixing with changing the type?

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.

It also looks like this change is causing type mismatch errors as boxcutter still expects int64 in some places.

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.

In that case we should revert it back to int64.

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.

Isn't this technically an API change (due to the size change)?

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.

And possibly a breaking change too from an API perspective.

@perdasilvaperdasilvaNov 17, 2025

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.

It seems to be best practice to use int32 if the extra precision isn't needed as it avoid issues with JSON serialization on some clients.

I don't have a big dog in this hunt since I don't think we'll experience the json serialization issues (since we'll never reach a number large enough for it to show up). I guess we could also cap the value at the JSON max int to avoid this? I'd also like to understand whether we think we need the extra precision and what do we lose by not having it...

It would be a breaking change. But, is my understanding correct that we are allowed to have breaking API changes while in experimental mode? Or is the expectation that we change the version? e.g. v1alpha2?

//
// +kubebuilder:validation:Required
// +kubebuilder:validation:Minimum:=1
// +kubebuilder:validation:Minimum=1

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.

The version with := is documented: https://book.kubebuilder.io/reference/markers/crd-validation

You can also see that this is a no-op change - check the generated CRD.

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.

Ah, I didn't know that. Is there value in using a single format in the CRDs we produce?

@perdasilvaperdasilva changed the title 🌱 Fix a few small issues with ClusterExtensionRevision API🌱 Add enum validation annotation to CollisionProtectionNov 17, 2025
Signed-off-by: Per Goncalves da Silva <pegoncal@redhat.com>
@codecov

codecovBot commented Nov 17, 2025

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.30%. Comparing base (c06f27f) to head (325050f).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files
@@ Coverage Diff @@## main #2334 +/- ##
=======================================
Coverage 74.30% 74.30% =======================================
Files 91 91 Lines 7083 7083 =======================================
Hits 5263 5263 Misses 1405 1405 Partials 415 415 
FlagCoverage Δ
e2e45.64% <ø> (ø)
experimental-e2e48.39% <ø> (ø)
unit58.60% <ø> (ø)

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.

@pedjakpedjak 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.

/lgtm

@openshift-ciopenshift-ciBot added the lgtm Indicates that a PR is ready to be merged. label Nov 17, 2025

@rashmigottipatirashmigottipati 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.

/lgtm

@tmshort

Copy link
Copy Markdown
Contributor

/approve

@openshift-ci

Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is APPROVED

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

@openshift-ciopenshift-ciBot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Nov 17, 2025
@openshift-merge-bot
openshift-merge-botBot merged commit bf7e39f into operator-framework:mainNov 17, 2025
25 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.

5 participants

@perdasilva@tmshort@pedjak@rashmigottipati