oc-installer does not understand semver, can't install 3.11.375-1

[anthonydahanne]

Version

redhat-actions/oc-installer@v1

Describe the bug

oc-installer does not understand oc_version such as 3.11.375-1 (it will strip anything after the bugfix number, in this case, it will change the input to 3.11.375) - works great with 3.11.374 though.

Steps to reproduce, workflow links, screenshots

With such configuration:

      - name: Install oc
        uses: redhat-actions/oc-installer@v1
        with:
          oc_version: '3.11.375-1'

oc-installer will fail to install oc :

Run redhat-actions/oc-installer@v1
  with:
    oc_version: 3.11.375-1

Installing oc version 3.11.375
Found oc version 3.11.375 at https://mirror.openshift.com/pub/openshift-v3/clients/3.11.375/linux/oc.tar.gz
Downloading oc from https://mirror.openshift.com/pub/openshift-v3/clients/3.11.375/linux/oc.tar.gz ...
Error: Error: Unexpected HTTP response: 404

Although 3.11.375-1 exists: https://mirror.openshift.com/pub/openshift-v3/clients/3.11.375-1/linux/

[tetchel]

is using the url input type an acceptable workaround? the code seems to be rather rigid in this.

      - name: Install oc
        uses: redhat-actions/oc-installer@v1
        with:
          oc_version: 'https://mirror.openshift.com/pub/openshift-v3/clients/3.11.375-1/linux/oc.tar.gz'

[tetchel]

this would also be satisfied by redhat-actions/openshift-tools-installer#1, you're just the first one to show a use-case for that feature :)

[anthonydahanne]

is using the url input type an acceptable workaround?

I guess, but not ideal though.

It's kind of problematic because versions such v3 for example will resolve to 3.11.375-1 and then fail.

[tetchel]

this action doesn't work with versions such as v3 - you have to provide an exact version.

are you thinking of the openshift-tools-installer?

[tetchel]

I provided oc: 3 to openshift-tools-installer here and it resolved to 3.11.374 since it drops the versions that can't be coerced to semver using their library.

[anthonydahanne]

yeah you're right I was confused with openshift-tools-installer my bad.

[tetchel]

so do you need

• this issue fixed in oc-installer
• or is the tools-installer meeting your needs
• or do you specifically need to install those suffixed versions

I don't know why they changed the v3 directory naming in january...

[anthonydahanne]

hey there @tetchel
Sorry for the long delay to answer you.
We're currently only using the oc-login action (and it's perfect the way it is! thanks!); I have installed the oc and helm CLIs on the runners (we're using GHES with self hosted runners) since we don't require specific versions of those CLIs - so I don't think we'll be using the oc-installer nor the openshift-tools-installer actions.
Not being able to leverage cache with such actions (redhat-actions/openshift-tools-installer#17 (comment)) is also a deal breaker IMO.

[tetchel]

I think your usage makes sense. I wouldn't be using 'installer' actions if I was using SH runners, either, but rather build them into the runner image.

are you using our self-hosted runner images or something else?

[anthonydahanne]

hello @tetchel !
Actually, no I'm not using the redhat-actions runner images; I wasn't aware of them, just had a look and they seem to be images definitions for runners running as pods in k8s.
At my organization (unfortunately behind a private git repo), we're using Terraform to provision a launch configuration + AutoScalingGroup; that allows us to provision our runners directly in AWS as EC2 instances; drawback is the lack of dynamicity in the deployment - we're living with it for now.
When we start running runners in k8s, I'll be sure to check your solution out; I had already identified:

• Another k8s based solution
• a popular AWS based solution

[tetchel]

OK, cool.

Well, to wrap this issue up I am going to close it in favour of redhat-actions/openshift-tools-installer#1 as linked above. Let me know if you have any other questions/comments/issues.