✅ Deploy Preview for olmv1 ready!

Name	Link
🔨 Latest commit	e0605c2
🔍 Latest deploy log	https://app.netlify.com/projects/olmv1/deploys/68adf9620324670008af449a
😎 Deploy Preview	https://deploy-preview-2145--olmv1.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

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

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 72.64%. Comparing base (dff07d5) to head (e0605c2).
⚠️ Report is 5 commits behind head on main.

@@            Coverage Diff             @@
##             main    #2145      +/-   ##
==========================================
- Coverage   72.79%   72.64%   -0.16%     
==========================================
  Files          79       79              
  Lines        7340     7347       +7     
==========================================
- Hits         5343     5337       -6     
- Misses       1651     1662      +11     
- Partials      346      348       +2     

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

From Claude Code:

● Helm Charts Analysis

This repository contains 3 Helm charts for the OLMv1 (Operator Lifecycle Manager v1) project:

1. olmv1 Chart (helm/olmv1/)

• Purpose: Main chart for deploying OLMv1 components
• Components:
  • Operator Controller (manages ClusterExtensions)
  • Catalogd (manages ClusterCatalogs)
  • Optional cert-manager integration
  • OpenShift-specific configurations
• Key Features:
  • Modular design - components can be enabled/disabled independently
  • Support for both standard and experimental feature sets
  • Comprehensive RBAC configuration
  • Network policies for security isolation
  • Multi-architecture support (amd64, arm64, ppc64le, s390x)

2. prometheus Chart (helm/prometheus/)

• Purpose: Monitoring stack for OLMv1
• Components: Prometheus instance with ServiceMonitors
• Monitors: Catalogd, operator-controller, and kubelet metrics

3. Configuration Files

• cert-manager.yaml, e2e.yaml, experimental.yaml, tilt.yaml - Environment-specific configurations

Security Best Practices Found:

✅ Strong Security Posture:

• runAsNonRoot: true in pod security contexts
• readOnlyRootFilesystem: true for containers
• allowPrivilegeEscalation: false
• All capabilities dropped (drop: [ALL])
• seccomp profile set to RuntimeDefault
• Principle of least privilege in RBAC roles
• Network policies for traffic isolation
• Node affinity constraints for control plane scheduling

✅ Operational Best Practices:

• Proper resource naming and labeling
• Graceful termination handling
• Health probes configuration
• Leader election for high availability
• Comprehensive monitoring integration

The charts follow Kubernetes and Helm best practices with a strong focus on security and operational excellence.

Recommend the use of https://github.com/homeport/dyff to evaluate the manifest YAML differences.

Review – Aug 26

I reviewed the diff and everything looks fine overall. 🥇 The only changes that caught my attention were:

• The selector change: https://github.com/operator-framework/operator-controller/pull/2145/files#r2272575728
• The certs name change: https://github.com/operator-framework/operator-controller/pull/2145/files#r2301592489

I commented on both of these. We moved to a "standard k8s" selector, but we can always put back the original if there are complaints.

See: #2145 (comment)

IMO, the only things missing are:

1. The Chart version should match the release version (we need to discuss how to keep this updated).

The chart version is the version of the chart itself, and is supposed to be incremented whenever the chart is modified. It's not necessarily supposed to match the software release. The field that corresponds the the release (appVersion) is optional and has been removed, so we don't need to keep it in sync.

# This is the chart version. This version number should be incremented each time you make changes
# to the chart and its templates, including the app version.
# Versions are expected to follow Semantic Versioning (https://semver.org/)
version: 0.1.0

# This is the version number of the application being deployed. This version number should be
# incremented each time you make changes to the application. Versions are not expected to
# follow Semantic Versioning. They should reflect the version the application is using.
# It is recommended to use it with quotes.
appVersion: "1.0.0"

We don't actually use the field when rendering.

2. Add a GitHub Action to run helm lint so that we can validate the Helm chart.

Not sure we need to add a new CI, we can do it as part of make manifests (which already does render some other options, i.e. tilt and openshift) which is part of the verify CI.

3. Optinally: Could we also test out helm install in a GitHub Action for now, just to ensure the chart is deployable? This would be a good stopgap until we start distributing the solution via Helm and use it to run our e2e tests.

This is a bit out-of-scope now. We are only planning to template/render it. We do use the rendered manifests for e2e testing.

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: camilamacedo86
Once this PR has been reviewed and has the lgtm label, please assign tmshort for approval. For more information see the Code Review Process.

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