Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
/cherrypick release-0.6 |
|
@xrstf: once the present PR merges, I will cherry-pick it on top of DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
51d2b87 to
95137c4
Compare
On-behalf-of: @SAP christoph.mewes@sap.com
Summary
These got lost in #188 and I see no reason why we should already stop testing against 0.28, a supported kcp release. With the current config, we effectively tested against kcp 0.30.1 and release-0.30.
The main difference is that kcp 0.28 doesn't have a release with support for authentication on the cache server, so the e2e tests fail. We already have some logic to kind of sort of detect the kcp release and skip certain tests, but the logic could not catch this particular case.
To make this more palatable, I reworked the concept a bit: The setup scripts for the e2e tests will now not just resolve the branch name (
release-0.30=>387ad6e), but also pull and re-tag the image, so387ad6ebecomes0.30.999. The re-tagged image is then preloaded into kind. The oldKCP_RELEASEhack was re-used to supply a suitable release forKCP_TAG=main, but is otherwise not used in the tests anymore.To actually handle the version differences, I added parsing logic to the image tag in the operator. If the tag fails to parse, no worries, we'll just use it but assume you have the latest and greatest kcp. If you need to opt-in to a specific release's treatment by the operator, tag your custom images with a semver.
What Type of PR Is This?
/kind cleanup
Release Notes