Disable arm container image builds

[oyvindio]

I've started looking into setting up the new release model for fiaas-deploy-daemon (#163). I think it makes sense to do that in a similar manner to fiaas/k8s, where there is a separate build stage for creating the release, which is only run for builds triggered by pushing a git tag. I'd also like to set up the e2e tests to run in parallel using a matrix build, since that should reduce CI build duration, and would speed up testing of the release builds.

I think it is important to use the same container image throughout the CI pipeline; from initial build stage, to the e2e build stages, to the release build stage. Unfortunately this seems to me to be a bit tricky to do with the way the fiaas-deploy-daemon container image is currently built. The current CI build builds a single-manifest multi-arch image for amd64, arm64 and arm7. This type of image can be exported as a tarball with docker buildx --output=type=tar, which the current build does, but it doesn't seem to be possible to actually import this tarball into docker (in later build stages), so that can be used to run a container or be pushed to a container registry. At least I haven't been able to figure out how. There also seems to be a few tickets on buildx related to this capability:

• https://github.com/docker/buildx/issues/847
• https://github.com/docker/buildx/issues/430
• https://github.com/docker/buildx/issues/393

Simple "single arch" images built docker build (i.e. not buildx) can be exported and imported to/from file with docker image save/load, and be moved through a CI pipeline that way. Building arm images was disabled in fiaas/skipper almost a year ago. That makes disabling arm container image builds for fiaas-deploy-daemon to work around the apparent limitations in the tooling for multi-arch images seem like a potential option, unless someone actually depends on the arm container images.

If you are using fiaas-deploy-daemon container images built for arm64/arm7, please comment here and we can discuss alternative solutions.

[mortenlj]

Initially, I set up arm builds to enable using fiaas in homelab clusters running on raspberry pi. Since then I've also made a cluster on oracle cloud using a combination of amd64 and arm64 instances (3 node cluster + database absolutely free for personal use).

In the sense "does anyone use this in their cluster", then I would like to say yes (although I'm not currently because TTT[1]). In the sense "does anyone need this for business", probably not.

The fact that multi-arch images can't be saved/loaded is a problem, but I have in other cases found that simply pushing the images with a tag that indicates a release candidate can solve the same problem. Once completed through CI, the image can simply be re-tagged with a production tag.

[1]: Things Take Time 🙂

[mortenlj]

In any case, armv7 can probably be dropped. Afaik, the relevant places one would use arm today all support arm64.

[oyvindio]

The fact that multi-arch images can't be saved/loaded is a problem, but I have in other cases found that simply pushing the images with a tag that indicates a release candidate can solve the same problem. Once completed through CI, the image can simply be re-tagged with a production tag.

In the approach I'm suggesting above it would be necessary to push images for every build, including branch and PR builds where the image is never going to be tagged as a release. It seems unnecessary to me to push and store images that will only be pulled once to run the e2e test.

In the sense "does anyone use this in their cluster", then I would like to say yes (although I'm not currently because TTT[1]). In the sense "does anyone need this for business", probably not.

While it is nice to have container images for arm, if these images are not actually used right now then it seems reasonable enough to me to remove them from the build for now to make it easier to set up a faster CI build and implement the new release model. If there is demand they can be added back later, maybe the tooling even improves so that it becomes easier to do. In the mean time it is also possible to build images for arm locally if necessary.

I've pushed a PoC of the unit test, (amd64 only) container image build and e2e matrix build parts of what I described above in the 163-semver-releases branch. I'd like to continue building on that to implement the new release model. Based on limited testing, in this branch the CI build duration seems around 4x lower than in master. This is mostly because of the matrix build configuration, although building the container image only for amd64 itself seems to save about a minute.