-
Notifications
You must be signed in to change notification settings - Fork 357
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: update generate_versions.go #2252
Conversation
Signed-off-by: Jayapriya Pai <janantha@redhat.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/label 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 |
@@ -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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes let's branch to unblock the CI, we'll try the other approach later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
JFYI This needs |
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
PR needs rebase. 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. |
/close this is already taken care in another PR |
@slashpai: The following tests 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-sigs/prow repository. I understand the commands that are listed here. |
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
/close |
@slashpai: Closed this PR. In 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. |
Follow-up of rhobs/syncbot#72