build: bump OCP_VERSION to 4.12

[dustymabe]

4.10 is a bit old at this point.

[dustymabe]

should we add bumping this to an SOP?

[jlebon]

I'd vote for just stopping pinning and always pulling the latest stable version? https://mirror.openshift.com/pub/openshift-v4/clients/ocp/latest/openshift-client-linux.tar.gz is an unversioned link.

Also relatedly, I just noticed that we're doing this on all arches, but we're always downloading the x86_64 one. Not all arches are available on the mirrors so we should probably gate the fetching logic to only x86_64.

[dustymabe]

I'd vote for just stopping pinning and always pulling the latest stable version? https://mirror.openshift.com/pub/openshift-v4/clients/ocp/latest/openshift-client-linux.tar.gz is an unversioned link.

I think that makes sense especially for latest COSA/FCOS/RHCOS devel, but when we branch COSA maybe it makes sense to freeze on one? Do we know what this is really used for in the pipeline(s) today?

Also relatedly, I just noticed that we're doing this on all arches, but we're always downloading the x86_64 one. Not all arches are available on the mirrors so we should probably gate the fetching logic to only x86_64.

+1

[jlebon]

I'd vote for just stopping pinning and always pulling the latest stable version? mirror.openshift.com/pub/openshift-v4/clients/ocp/latest/openshift-client-linux.tar.gz is an unversioned link.

I think that makes sense especially for latest COSA/FCOS/RHCOS devel, but when we branch COSA maybe it makes sense to freeze on one? Do we know what this is really used for in the pipeline(s) today?

It was initially added for testing the layering stuff in Prow (#2777), but I'm not sure if that test still exists today (the bit it linked to is no longer there). This script uses it, but I don't see anything on the openshift/release side calling that script. On the pipeline side, we use it for a single oc get. The bigger value honestly is probably that it's already in the container image for devs to use. Cool with pinning on branching, but not sure it's worth it given that we don't really use advanced features from it that would be more likely to regress.

[dustymabe]

Also relatedly, I just noticed that we're doing this on all arches, but we're always downloading the x86_64 one. Not all arches are available on the mirrors so we should probably gate the fetching logic to only x86_64.

I took a new look at this. I think we are downloading it for the arches correctly given we are calling "$(arch)" in there:

coreos-assembler/build.sh

Line 106 in d80b183

curl -L https://mirror.openshift.com/pub/openshift-v4/"$(arch)"/clients/ocp/latest-$OCP_VERSION/openshift-client-linux.tar.gz | tar zxf - oc \

[jlebon]

Also relatedly, I just noticed that we're doing this on all arches, but we're always downloading the x86_64 one. Not all arches are available on the mirrors so we should probably gate the fetching logic to only x86_64.

I took a new look at this. I think we are downloading it for the arches correctly given we are calling "$(arch)" in there:

coreos-assembler/build.sh

Line 106 in d80b183

curl -L https://mirror.openshift.com/pub/openshift-v4/"$(arch)"/clients/ocp/latest-$OCP_VERSION/openshift-client-linux.tar.gz | tar zxf - oc \

Ahh nice, missed that. I was confused by the fact that the final directory containing the artifacts (e.g. this one) nonetheless appears to have e.g. both x86_64 and aarch64 versions, but not the others. Likely for historical reasons?

[dustymabe]

Likely for historical reasons?

yeah not sure.

[jlebon]

Good with this too if we want to defer the unpinning to a follow-up.

[dustymabe]

Good with this too if we want to defer the unpinning to a follow-up.

i'll unpin here will get back to it soon.

[dustymabe]

updated