Refine OSC version bump workflow

Bumping OSC version is a bit tricky as it should happen at many
locations scattered everywhere in the tree. Commit e2a4c34
introduced an `OSC_VERSION` tag to help tracking these locations.

Unfortunately, `make bundle` wreaks havoc in this logic as it
overwrites lines at several locations and drops the tag:
- everywhere in the `bundle` directory
- some locations in the base CSV
- a single location in `config/manager/kustomization.yaml`

As a result, we can only rely on `OSC_VERSION` for a subset of
the locations that need care. The other ones are:
- the `olm.skipRange` annotation in the base CSV
- the `spec.version` field in the base CSV
- the `spec.replaces` field in the base CSV

`make bundle` should then be run to propagate the version bump
to the rest of the repo.

Document all that.

While here set the tag for the metrics-server container that was
recently added.

Signed-off-by: Greg Kurz <[email protected]>
(cherry picked from commit 1c33256)
Signed-off-by: Greg Kurz <[email protected]>

Author: gkurz

config/metrics/metrics-deployment.yaml

@@ -17,7 +17,7 @@ spec:
     spec:
       containers:
         - name: metrics-server
-          image: registry.redhat.io/openshift-sandboxed-containers/osc-monitor-rhel9:1.8.0
+          image: registry.redhat.io/openshift-sandboxed-containers/osc-monitor-rhel9:1.8.0  ## OSC_VERSION
           command: ["/metrics-server"]
           ports:
             - containerPort: 8091

docs/DEVELOPMENT.md

@@ -131,20 +131,33 @@ Uncomment all entries marked with `[CERTMANAGER]` in manifest files under `confi
 make install && make deploy
 ```
 
-### Updating versions
+### Adding new containers to OSC
 
-When starting a new version, the locations tagged with `OSC_VERSION` should be updated with the new version number. A few places are also tagged with `OSC_VERSION_BEFORE`, referring to the version being replaced.
+When adding a new container definition in some pod yaml, make sure to tag the `image`
+field with `OSC_VERSION`, e.g.
 
-On the  `main` branch `1.5.2`, the following locations were identified, but looking for the version pattern would give too many false positives on `devel` with `1.7.0`, and even more false positives were found with `1.8.0`. Most hits were in `go.mod` or `go.sum` and should be ignored, since they refer to dependencies with unrelated version numbering.
+```
+image: registry.redhat.io/openshift-sandboxed-containers/osc-monitor-rhel9:1.8.0  ## OSC_VERSION
+```
+
+Do the same when adding new `RELATED_IMAGE` entries in the environment of the controller
+in `config/manager/manager.yaml`, e.g.
 
 ```
-Makefile:6:VERSION ?= 1.5.2
-config/manager/kustomization.yaml:16:  newTag: 1.5.2
-config/manifests/bases/sandboxed-containers-operator.clusterserviceversion.yaml:16:    olm.skipRange: '>=1.1.0 <1.5.2'
-config/manifests/bases/sandboxed-containers-operator.clusterserviceversion.yaml:28:  name: sandboxed-containers-operator.v1.5.2
-config/manifests/bases/sandboxed-containers-operator.clusterserviceversion.yaml:368:  version: 1.5.2
-config/samples/deploy.yaml:9: image:  quay.io/openshift_sandboxed_containers/openshift-sandboxed-containers-operator-catalog:v1.5.2
-config/samples/deploy.yaml:39:  startingCSV: sandboxed-containers-operator.v1.5.2
-hack/aws-image-job.yaml:24:        image: registry.redhat.io/openshift-sandboxed-containers/osc-podvm-payload-rhel9:1.5.2
-hack/azure-image-job.yaml:23:        image: registry.redhat.io/openshift-sandboxed-containers/osc-podvm-payload-rhel9:1.5.2
+            - name: RELATED_IMAGE_KATA_MONITOR
+              value: registry.redhat.io/openshift-sandboxed-containers/osc-monitor-rhel9:1.8.0  ## OSC_VERSION
 ```
+
+This is a best effort to track locations where OSC version bumps should happen.
+
+### Updating versions
+
+When starting a new version, several locations should be updated with the new version number :
+- all the locations tagged with `OSC_VERSION`
+- the `spec.version` field in `config/manifests/bases/sandboxed-containers-operator.clusterserviceversion.yaml`
+- the `olm.skipRange` annotation in the `spec.metadata` field in `config/manifests/bases/sandboxed-containers-operator.clusterserviceversion.yaml`
+
+The `spec.replaces` field in `config/manifests/bases/sandboxed-containers-operator.clusterserviceversion.yaml` should be updated with the number
+of the latest officialy released version.
+
+Finally, run `make bundle` : this should propagate the version bump to the rest of the tree.