Update Makefile to handle old versions in OLM

[fperearodriguez]

Proposed changes

Only the latest version of the Operator is available in the certified-operators index. I am unsure if that configuration is intentional or not, but I have verified that all the images are available in Quay. The issue appears to be with the creation of the OLM bundle, and I would like to propose keeping the old versions of the operator available [1].

This PR updates the Makefile to configure OLM to keep an old version of the operator available:

• skips: [] -> Which means all versions will be available in the catalog and can be part of the upgrade chain.
• replaces -> Needed to create an upgrade path. In most cases, it is the previous one.

[1] #540

Checklist

Before creating a PR, run through this checklist and mark each as complete.

• I have read the CONTRIBUTING doc
• I have added tests that prove my fix is effective or that my feature works
• I have checked that all unit tests pass after adding my changes
• I have updated necessary documentation
• I have rebased my branch onto main
• I will ensure my PR is targeting the main branch and pulling from my branch from my own fork

[github-actions]

✅ All required contributors have signed the F5 CLA for this PR. Thank you!
_{Posted by the CLA Assistant Lite bot.}

[fperearodriguez]

I have hereby read the F5 CLA and agree to its terms

[haywoodsh]

We are currently investigating the possibilty of making older operator bundles available on OpenShift by converting the repo to file based catalog nginx/kubernetes-ingress#8222, but this PR also appears to be a solution to make the immediate previous version of the bundle available. I wonder if both solutions can co-exist?

For the implementation, I am wondering if we have to make .spec.replaces optional. Any downsides missing or having the wrong one in the CSV?

Also, during release, we update the operator version from current to the new automatically with the pipeline (see https://github.com/nginx/nginx-ingress-helm-operator/blob/main/.github/workflows/sync-chart.yml). I think we will need to find a way to automate updating REPLACES from previous version to current to avoid additional PRs.

[fperearodriguez]

Thanks for your comment @haywoodsh. Honestly, the PR is a quick patch to keep all the versions available for the current model (metadata-bundle based), but the right approach is to convert the repo to FBC (file based catalog) since you are already considering it.

If you decide to switch to FBC [1], you will use the olm.package, olm.channel, and olm.bundle to manage the whole lifecycle of all versions in a declarative way. Besides, you can create an upgrade path [2] in which you will configure which version replaces the old one. That information will be placed in the olm.channel file.

Answering your questions:

 wonder if both solutions can co-exist?

I don't think both implementations must be done at the same time. For the short term, applying the skip/replaces in the CSV file will configure the catalog/bundle to include all versions (as per the current PR).

For the implementation, I am wondering if we have to make .spec.replaces optional. Any downsides missing or having the wrong one in the CSV?

Needed, but not mandatory. Helpful if you want to have an upgrade path.

About the pipeline, I guess, depending on the decision you take. With FBC, you don't need that variable, but you do need the variable with the current PR approach, agree.

[1] https://olm.operatorframework.io/docs/reference/file-based-catalogs/#olm-defined-schemas
[2] https://olm.operatorframework.io/docs/concepts/olm-architecture/operator-catalog/creating-an-update-graph/#methods-for-specifying-updates

[jmighion]

@haywoodsh any chance this can be merged? We're hoping to get some stability from having a known good version to install in case something happens.

[fperearodriguez]

@haywoodsh - Added the code to add the REPLACES with the pipeline automatically. At this point, with the changes to the Makefile and sync-chart.yml files, the upgrade path to the N-1 version must be followed.

After a deep review of the code, I confirmed that the Makefile is already set up to add older versions to the catalog, see Makefile. This is an essential step too, so when the Upgrade is triggered, the variable CATALOG_BASE_IMG must be used to build the new one.

[Copilot]

Pull Request Overview

This PR updates the OLM (Operator Lifecycle Manager) bundle generation process to maintain an upgrade path between operator versions in the certified-operators catalog. Previously, only the latest version was available; this change ensures older versions remain accessible and properly linked through OLM's upgrade mechanism.

Key Changes:

• Adds REPLACES variable to define upgrade path from previous operator versions
• Configures skips: [] to make all versions available in the catalog
• Updates CI workflow to automatically set REPLACES to the current version before incrementing

Reviewed Changes

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

File	Description
Makefile	Adds REPLACES variable and bundle generation logic to inject OLM upgrade metadata (replaces/skips fields) into ClusterServiceVersion
.github/workflows/sync-chart.yml	Adds workflow step to update REPLACES value to current version before version bump

---

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

[vepatel]

#575 (comment)

[vepatel]

tested in local crc environment!