Skip to content

Conversation

@perdasilva
Copy link
Contributor

@perdasilva perdasilva commented Nov 14, 2025

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 owner November 14, 2025 16:09
Copilot AI review requested due to automatic review settings November 14, 2025 16:09
@netlify
Copy link

netlify bot commented Nov 14, 2025

Deploy Preview for olmv1 ready!

Name Link
🔨 Latest commit 325050f
🔍 Latest deploy log https://app.netlify.com/projects/olmv1/deploys/691afac61ab1ef0008077863
😎 Deploy Preview https://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.

Copilot finished reviewing on behalf of perdasilva November 14, 2025 16:11
Copy link

Copilot AI left a comment

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.

File Description
api/v1/clusterextensionrevision_types.go Fixed validation typo, added CollisionProtection enum validation, and changed Revision field from int64 to int32
manifests/experimental.yaml Updated generated CRD manifest with CollisionProtection enum values and int32 format for Revision
manifests/experimental-e2e.yaml Updated generated e2e CRD manifest with CollisionProtection enum values and int32 format for Revision
helm/olmv1/base/operator-controller/crd/experimental/olm.operatorframework.io_clusterextensionrevisions.yaml Updated 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.

Copy link
Contributor

@pedjak pedjak left a comment

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

Copy link
Contributor Author

@perdasilva perdasilva Nov 17, 2025

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
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
Contributor Author

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?

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

codecov bot commented Nov 17, 2025

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           
Flag Coverage Δ
e2e 45.64% <ø> (ø)
experimental-e2e 48.39% <ø> (ø)
unit 58.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.

Copy link
Contributor

@pedjak pedjak left a comment

Choose a reason for hiding this comment

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

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Nov 17, 2025
Copy link
Member

@rashmigottipati rashmigottipati left a comment

Choose a reason for hiding this comment

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

/lgtm

@tmshort
Copy link
Contributor

tmshort commented Nov 17, 2025

/approve

@openshift-ci
Copy link

openshift-ci bot commented Nov 17, 2025

[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

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-ci openshift-ci bot 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-bot bot merged commit bf7e39f into operator-framework:main Nov 17, 2025
25 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants