Multiplatform build

[f1ames]

This PR fixes multi-platform build for specific arm architectures. Before it got stuck on npm ci... command (e.g. https://github.com/kubeshop/monokle-admission-controller/actions/runs/6745376525/job/18337069349#step:8:399).

There is an issues with Node v19+ and arm based images. It is described in nodejs/docker-node#1794 and nodejs/docker-node#1335. At this moment it works with v18 based images and so I downgraded to it.

It builds fine with such changes (see this run https://github.com/kubeshop/monokle-admission-controller/actions/runs/6768309227/job/18392485679).

Changes

• As described above.

Fixes

• None.

Checklist

• tested locally
• added new dependencies
• updated the docs
• added a test

[murarustefaan]

First of all, why are we building for these many ARM versions?

MacOS, which was the source of this issue, is using arm v8 on 64-bit platforms. Therefore, the other build architectures are really useful for ppl running on Raspberry PI Model 3B and below. Again, While the good practice would be supporting that, I'm not sure it's worth pinning to a lower-than LTS image version of the node interpreter just for that sole purpose.

Secondly, Node LTS is 20, not 18, yet the image you are pinning to resolves to both Node18 as well as an older version of alpine.

Therefore, what I suggest first removing all unused architectures (anything but arm v8 and amd64), using Node20 with a pinned version instead of using lts tags (because as you saw, some of them are not updated and you might get older image versions or you will not know which one you are on) and then either trying the Google Distroless images (as that is a best practice for these kinds of containers) or go node-slim if alpine is still not working.

What do you think @f1ames?

[f1ames]

First of all, why are we building for these many ARM versions?

MacOS, which was the source of this issue, is using arm v8 on 64-bit platforms. Therefore, the other build architectures are really useful for ppl running on Raspberry PI Model 3B and below. Again, While the good practice would be supporting that, I'm not sure it's worth pinning to a lower-than LTS image version of the node interpreter just for that sole purpose.

Secondly, Node LTS is 20, not 18, yet the image you are pinning to resolves to both Node18 as well as an older version of alpine.

Good point. Yes, I just thought of it as a good practice to provide support for multiple architectures. But as you say, it might be not needed, it's also not our target audience at this point.
Now, as for pinning down to v18, it also seems to be an issue for arm v8 so dropping others will not help here (I can recheck to be 100% sure).

And the entire reason for downgrading was that for arm architecture, there is an issue with npm i starting from node v19, so that's why I downgraded to v18.

Therefore, what I suggest first removing all unused architectures (anything but arm v8 and amd64), using Node20 with a pinned version instead of using lts tags (because as you saw, some of them are not updated and you might get older image versions or you will not know which one you are on) and then either trying the Google Distroless images (as that is a best practice for these kinds of containers) or go node-slim if alpine is still not working.

Sure, it make sense. Just as I mentioned above it seems that even for linux/arm64/v8 only, it will not build with node v19+. In that case, would it make sense to build with node v18 and have production image using v20 (based on alpine or distroless you mentioned)?

[f1ames]

@murarustefaan let me know if you plan to do more tweaking here. I tested built image and it runs fine. From my perspective it's ready to be merged (apart from reverting commented stuff).

[murarustefaan]

lgtm!
please do not forget to revert all commented changes before merging :D