How can I configure container images for jobs?

[hartwig-wutscher-ibm]

I have some steps that run in a custom Image, e.g.

  test-and-sonar-scan:
    environment: default
    runs-on: [ self-hosted ]
    container:
      image: sonarsource/sonar-scanner-cli:4
   steps:
     [ ... ]

This results in the following error:

Current runner version: '2.284.0'
Runner name: '****'
Runner group name: 'bwi-runner'
Machine name: '****'
GITHUB_TOKEN Permissions
Prepare workflow directory
Prepare all required actions
Getting action download info
Download action repository 'actions/checkout@v2' (SHA:5a4ac9002d0be2fb38bd78e4b4dbde5606d7042f)
Error: docker: command not found

I've tried using the podman runner image adapted so it uses podaman as a drop-in replacement for, but that opened a whole host of new issues.

Is there a proper way to configer the runner to be running a job in a defined container?

[ViktorLindgren95]

This is a problem we also have, Docker actions dont seem to be supported by the Openshift runners as they dont have docker installed, and because the docker action is compiled in the pre-job part of the job, you cant manipulate it in any way. If im not mistaken this is a fault on the Github Actions side, by them not allowing you to define that you are using podman instead of docker for these types of operations.

For sonarqube specifically, At my work we instead just built a compose action with the binary inside the repository, and just added it to path inside the action and ran it. Its dirty but it works.

Hopefully that sheds some light on it. Im not a redhat guy Fyi

EDIT: just noticed you arent running the sonarqube docker action but the container itself. Some of the things still apply.

[tetchel]

In general, you can use a custom image as follows:

1. Build your own OpenShift-compatible runner image with the dependencies you need. You cannot just drop in an image not built with this in mind because it has to set a number of environment variables and set up the user. Doc here
2. When installing the chart, set the runnerImage and runnerTag values to your custom image. (ref. values.yaml)
3. If you have multiple types of self-hosted runners and need to distinguish them so different jobs can run on them, you can use the runnerLabels value. There's an example of this in this workflow where our node runner is installed with that label, and then the job run later in the workflow uses the labels [ self-hosted, node ].

As pointed out by Viktor above for your specific use-case - the container input will not help you here since it runs docker. Running docker is an orthogonal issue here since I suspect you just want to run your actions in a compatible version of the sonarsource/sonar-scanner-cli image which should be possible using the steps above.

Using docker

I haven't investigated using docker in the OpenShift runners. It likely would not be straightforward due to OpenShift's permissions model, buildah/podman are possible because they can run rootlessly and don't require a daemon. It may be possible using privileged containers. We do have a prebuilt runner which has buildah and podman but if you (or Actions) is literally running docker then obviously you will still have a command not found issue.

If you're feeling adventurous, you could try adding some code to our podman containerfile which aliases docker to podman since their CLIs are usually compatible.

[ViktorLindgren95]

My team has experimented with alias and it doesn't work, the call structure isn't the same so it's not a 1:1 replacement exactly . That's why we resorted to either doing what you suggested , baking the image with the image or building a compose or js action ( best practice) .

…

On Wed, Feb 9, 2022, 19:12 Tim Etchells ***@***.***> wrote: In general, you can use a custom image as follows: 1. Build your own OpenShift-compatible runner image with the dependencies you need. Doc here <https://github.com/redhat-actions/openshift-actions-runners/tree/main/base#own-image> 2. When installing the chart, set the runnerImage and runnerTag values to your custom image. (ref. values.yaml <https://github.com/redhat-actions/openshift-actions-runner-chart/blob/main/values.yaml> ) 3. If you have multiple types of self-hosted runners and need to distinguish them so different jobs can run on them, you can use the runnerLabels value <https://github.com/redhat-actions/openshift-actions-runner-chart/blob/main/values.yaml#L46>. There's an example of this in this workflow <https://github.com/redhat-actions/openshift-actions-runner-installer/blob/main/.github/workflows/repo_example.yml> where our node runner is installed with that label, and then the job run later in the workflow uses the labels [ self-hosted, node ]. As pointed out by Viktor above for your specific use-case - the container input will not help you here since it runs docker. Running docker is an orthogonal issue here since I suspect you just want to run your actions in the sonarsource/sonar-scanner-cli image which should be possible using the steps above. Using docker I haven't investigated using docker in the OpenShift runners. It likely would not be straightforward due to OpenShift's permissions model, buildah/podman are possible because they can run rootlessly and don't require a daemon. We do have a prebuilt runner which has buildah and podman <https://github.com/redhat-actions/openshift-actions-runners/tree/main/buildah> but if you (or Actions) is literally running docker then obviously you will still have a command not found issue. If you're feeling adventurous, you could try adding some code to our podman containerfile which aliases docker to podman since their CLIs are usually compatible. — Reply to this email directly, view it on GitHub <#18 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFRJY4G5ZMS6P3CAXF7OQWTU2KU7PANCNFSM5MVCTLFA> . You are receiving this because you commented.Message ID: ***@***.*** .com>