Fix runner container image

[stefanotorresi]

This PR introduces the usage of multi-target Dockerfile builds, to produce to separate containers for the web and the runner components.

The problem we originally had is that the image didn't include ssh, so the runner woudn't work properly, causing all the checks to be reported as passing, while actually they would not be executed at all.

It also does the following:

• some other misc renaming in the CI jobs
• updates the Helm charts accordingly
• the Helm charts now will install the rolling tag by default
• appVersion is gone, the only place where we need to update the pinned version are the bash installers.

[dottorblaster]

Could we avoid this? ._.

[stefanotorresi]

hmm, what do you mean?

[rtorrero]

I guess @dottorblaster means to ask if we could avoid the pullPolicy: Always? If so, I understood this is a side effect of using tag: rolling (to ensure the image gets pulled even when the tag is the same).

[dottorblaster]

I mean, for now I think it's useful to have an Always pullPolicy and point to the rolling tag but keep in mind that this will end up in the hands of customers, and I don't know if this is the best strategy to handle the distribution of the containers 🙂

@rtorrero anticipated my answer, Github was down while I was posting this comment :D

[stefanotorresi]

Maybe I'm missing something, but I don't see anything particularly problematic about Always: the container engine will not waste bandwidth if the image hash is identical, but by using Always we at least enforce to check if there is a new image available, otherwise it will keep using whatever it has already in cache under that repo:tag.
TL;DR: I'm not aware of good reasons not to use it, even for non-rolling tags, and it will surely avoid upgrading headaches.

[rtorrero]

LGTM