-
Notifications
You must be signed in to change notification settings - Fork 7
adding smoother install for serverless #473
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: matzew 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 |
EOF | ||
function install_serverless(){ | ||
header "Installing Serverless Operator" | ||
git clone https://github.com/openshift-knative/serverless-operator.git /tmp/serverless-operator |
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.
We don't always want to install the master of serverless, do we? Think about once we cut a release branch - we'll want the test to install the appropriate version of the serverless operator based on the release branch. But with this change, older versions of eventing in that release branch will still install the master (ie latest) of the serverless operator.
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.
the idea is that HEAD (release-next) would always go with master from that repo.
but we could stick to desired versions e.g. 1.5.0 and update, when needed
for the 0.13.0 bits, I wanted to wait until we have 1.5.0 out, and then use that - instead of HEAD/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.
That makes sense. I'm just worried we'll forget to update this every time we cut a new branch and end up accidentally testing against the wrong thing.
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.
yeah, but I think even the other way around, means some changes are needed. I am not sure what's best to avoid that
abc5f29
to
afbf82b
Compare
/retest |
392cfd3
to
afbf82b
Compare
/close needed to only verify the build ... |
@matzew: 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/test-infra repository. |
No description provided.