ERROR: failed to build: docker exporter does not currently support exporting manifest lists
The reason is that the “Build docker image” step cannot be used for multi-architecture builds. I want the Docker image to support both linux/amd64 and linux/arm64 as platform arguments. This allows to use specific docker image for test runner and fix performance issues.
My suggestion is to make the “Build docker image” step load: false and push: false. I have tried this in my fork, it works and solved performance issues. The proposed changes are here:
IIUC the test image is used by Exercism’s backend test runners to test the solutions. The images are pre-built and pushed to the test VMs. The test VMs are likely all the same one architecture.
What’s the use case for having the test image built for other architectures and how would that impact the existing test setup?
What’s the use case for having the test image built for other architectures and how would that impact the existing test setup?
swift-docker-base is used as a base image for swift-test-runner. Apart from being used for infrastructure, it is also used locally by maintainers and contributors. Until it is mentioned somewhere in the README, it’s hard to understand that running benchmarks on an arm machine with an amd Docker build will give misleading results. From this perspective, this is mainly for maintainers’ and contributors’ convenience.
I have this discussion in mind about switching machines to ARM as possible way to improve test runner performance. Although that would also mean using only one architecture in the end, it seemed simple and free to add arm support now, and avoid forgetting to change the platform later—which will almost certainly result in a performance drop.
This should not impact the existing test setup, as Docker will automatically select the appropriate architecture during the test runner build.
Technically: load and push achieve, that your image lives in a stable space outside the current Docker build instance. Without it, they only live in the cache of the current Docker build instance using no externally available names (image names) or files to store in GitHub Action job caches. That is not reliable, as GitHub might switch everything between job steps.
The Docker docs do not split build and push across multiple steps like Exercism does. But they also show how to use load with a multi-architecture build. To make that work, add a containerd configuration step like you add QEMU before building.
Yeah, that’s what @mk-mxp mentioned above. The load: true works if there is "containerd-snapshotter": true in setup docker step. I’ve updated the PR, but the new commits are not visible cause PR is closed.
Would you happen to know anyone I could respectfully ask for such a favour? It seems I might otherwise be waiting quite a long time for a volunteer, if not forever.
I would like to help, but have no idea what @ErikSchierboom wants someone to do. I never heard of “publishing” without being used live then by everybody.
@mk-mxp That’s actually an interesting question. As far as I know, the website does not use this workflow to build the Docker image, so it should be safe. All runners, analyzers, etc., are using this workflow. There should not be any difference for them, since the default platform is x64 and the build machines are x64 as well—so no new cross-platform builds are expected.
Other problem I can imagine is increased build time for deploy jobs, for builds without cache. It took 8 minutes for swift-docker-base for both architectures. Actually, i can compare with old setup myselft too.
So, the only scenario I can imagine that can be tested is building an image with this workflow for any repository from this list and verifying that it works locally.
@ErikSchierboom Am I right in understanding that you are suggesting we do the same thing I did with swift-docker-base: build it in a fork, push it to a “staging” hub, and test that it works? Or are you suggesting something else?
Maybe we are thinking to complicated here: The image is currently not used by the Swift track (test runner etc.), right? So @ErikSchierboom could safely merge this, without any risk for the students experience or website operations.
After that we are able to try out the docker image in the test-runner / analyzer repositories. There it gets into contact with production systems.
Not really. The PR is precisely for the workflow used by all track-related repos and would thus break all deploys if it didn’t work correctly. What I would like is for someone to
Cange their tooling repo’s usage of the docker-build-push-image.yml workflow to the branch used by the PR
