STF 1.5.4 release ops #158
Conversation
* [zuul] Add zuul job to SGO Depends-On: http://github.com/infrawatch/service-telemetry-operator/pull/512
[zuul] Use the stf-crc-jobs project template Instead of updating the .zuul.yaml file everytime infrawatch/service-telemetry-operator adds a new job, the project-template can be updated in STO, which will propogate the change to the project and avoid leaving gaps in testing. Depends-On: http://github.com/infrawatch/service-telemetry-operator/pull/514
Support STF 1.5.3 starting at OpenShift version 4.12 due to incompatibility with 4.11 due to dependency requirements. Our primary target is support of OCP EUS releases. Related: STF-1632
Support OCP v4.12 through v4.14
The way we generate our CSVs uses OLM's skipRange functionality. This is fine, but using only this leads to older versions becoming unavailable after the fact -- see the warning at [1]. By adding an optional spec.replaces to our CSV we allow update testing as well as actual production updates for downstream builds that leverage it. Populating the field requires knowledge of the latest-released bundle, so we take it from an environment variable to be provided by the builder. If this is unset we don't include the spec.replaces field at all -- leaving previous behavior unchanged. Related: infrawatch/service-telemetry-operator#559 Related: STF-1658 [1] https://olm.operatorframework.io/docs/concepts/olm-architecture/operator-catalog/creating-an-update-graph/#skiprange
Add optional spec.replaces field to CSV for update graph compliance
STF can now be deployed in disconnected mode. This change updates the features.operators.openshift.io/disconnected annotation to reflect this.
…port-annotation Set features.operators.openshift.io/disconnected to True
I think this happens due to the previous merge being a squash+merge. Look here: #149 The last commit in that PR is 0531e69, but then it says "leifmadsen merged commit 519e2eb". Because of that, this merge sees these as entirely new commits, but producing the same content. Upshot is that while squash+merge is good for consolidating a PR that takes multiple revisions, I don't think it's good for preserving history when synchronizing branches. |
Ah thanks for that. Makes sense now. I guess in this case we want to use Merge and not the Squash and Merge option to avoid this in the future? |
No description provided.