fix: update generate_versions.go #2252
Conversation
Signed-off-by: Jayapriya Pai <janantha@redhat.com>
openshift-ci
bot
added
the
approved
|
/label acknowledge-critical-fixes-only |
openshift-ci
bot
added
the
acknowledge-critical-fixes-only
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jan--f, simonpasquier, slashpai The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@slashpai: The following test failed, say
Full PR test history. Your PR dashboard. 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/test-infra repository. I understand the commands that are listed here. |
| @@ -181,7 +181,7 @@ func getVersion(repo, ref string) (string, error) { | |||
| baseURL := fmt.Sprintf("https://raw.githubusercontent.com/%s/%s", repo, ref) | |||
| link := fmt.Sprintf("%s/VERSION", baseURL) | |||
| if repo == metricsServerRepo { | |||
| link = fmt.Sprintf("%s/manifests/release/kustomization.yaml", baseURL) | |||
| link = fmt.Sprintf("%s/manifests/components/release/kustomization.yaml", baseURL) | |||
There was a problem hiding this comment.
I'm afraid we'll have to branch as before v0.7.0, the file was in fact at /manifests/release/kustomization.yaml: https://github.com/kubernetes-sigs/metrics-server/blob/v0.6.4/manifests/release/kustomization.yaml
we started using v0.7.0 in 4.16, so we can branch on that.
Or fallback to the other path on a 404, as you want :)
There was a problem hiding this comment.
I didn't check, but maybe we could add a VERSION file in our downstream?
syncbot should know the tag, we could just ask to put it there...
There was a problem hiding this comment.
Yes let's branch to unblock the CI, we'll try the other approach later.
There was a problem hiding this comment.
Just to confirm, if https://github.com/openshift/release/blob/master/ci-operator/config/openshift/cluster-monitoring-operator/openshift-cluster-monitoring-operator-release-4.16.yaml and https://github.com/openshift/release/blob/master/ci-operator/config/openshift/cluster-monitoring-operator/openshift-cluster-monitoring-operator-release-4.15.yaml are sourced from the respective branches instead of master, wouldn't that automatically fix things for us?
There was a problem hiding this comment.
(since this commit won't go into 4.15 as it's out, and only 4.16 will be up-to-date with master?)
There was a problem hiding this comment.
But with the code from master we fetch versions for 4.14 and 4.17, so it should be compatible with both.
There was a problem hiding this comment.
Right, I was confused by that. Could you elaborate a bit on the branching approach, since we already have branches till 4.17 on both (I'm not sure what exactly the "branching" entails here)? I'd also like to reiterate the idea of having a conditional that checks both /manifests/release/kustomization.yaml and /manifests/components/release/kustomization.yaml for a 200, and goes with that, which would fix things on both fronts. We can drop the older path once the CMO versions using them correspond to EOL releases. WDYT?
There was a problem hiding this comment.
Sorry, I wasn't explicit, by branching I mean "conditional branching": adding a condition on the version (we're talking about the same thing :))
|
/hold |
openshift-ci
bot
added
the
do-not-merge/hold
|
JFYI This needs |
Follow-up of rhobs/syncbot#72