When using the extended channel, also specify the cluster version

[julianKatz]

<What type of PR is this?

Uncomment only one /kind <> line, hit enter to put that in a new line, and remove leading whitespaces from that line:

/kind api-change
/kind bug
/kind cleanup
/kind design
/kind documentation

/kind failing-test

/kind feature
/kind flake

What this PR does / why we need it:

When running CI for the extended channel, we intended to specify both the release channel and the version of the cluster. However, the CI test script was choosing only one of the two depending on the setting of the release channel.

This PR adds a special case of for extended, where both the release channel and the cluster version are passed to the test automation.

Does this PR introduce a user-facing change?:

None

[k8s-ci-robot]

Hi @julianKatz. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[mattcary]

/ok-to-test

[mattcary]

Does this work if $gke_release_channel is empty? I'm always a little confused by bash parsing, but if the string is empty you may end up with if [ = extended ] which is a parse error

[julianKatz]

Good catch, I did a little more looking and I believe I've got a better version now.

That first part is right AFAICT. gke_release_channel is defaulted to empty string in its var declaration and Stackoverflow says [ thing = otherThing ] is the right POSIX solution for string equality checks.

The second one was more ambiguous. I've changed it to check for a non-empty variable:

  elif [ -n "$gke_release_channel" ]; then

[mattcary]

ah, the quotes matter. [ $unknown = foo ] fails to parse, but [ "$unknown" = foo ] is okay. Interesting.

+1 to using -n, it's a little more clear (although [ ] seems to be valid anyway)

[mattcary]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: julianKatz, mattcary

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:

• OWNERS [mattcary]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment