fix: no match for platform in manifest when containerd is enabled#9200
Merged
eddumelendez merged 1 commit intotestcontainers:mainfrom Sep 17, 2024
Merged
Conversation
Member
|
I've used redis:3.2.4-alpine using Docker Desktop for Mac M1 and the image has been downloaded and test executed successfully. Do you have a public image to reproduce the issue? |
Contributor
Author
|
Yes, Here's a simple reproducer in Kotlin: import org.testcontainers.images.RemoteDockerImage
import org.testcontainers.utility.DockerImageName
fun main() {
RemoteDockerImage(
DockerImageName.parse("gradle:8.6.0-jdk17-alpine")
).get()
} |
Member
|
Thanks for sharing, @monosoul. However, I am not able to reproduce it on my MAC M1 using Docker Desktop and Testcontainers 1.20.1. The same image has been downloaded successfully @Test
void test() throws IOException, InterruptedException {
new RemoteDockerImage(DockerImageName.parse("gradle:8.6.0-jdk17-alpine")).get();
try (final GenericContainer<?> redis = new GenericContainer<>("gradle:8.6.0-jdk17-alpine")
.withCreateContainerCmdModifier(cmd -> cmd.withEntrypoint("sh", "-c", "while true; do sleep 1; done"))) {
redis.start();
org.testcontainers.containers.Container.ExecResult ping = redis.execInContainer("gradle", "help");
System.out.println(ping.getStdout());
}
}output: Logs show |
Contributor
Author
|
This is what I get trying to run the same test 🤔 I have a team license for Docker Desktop, I wonder if it can have anything to do with the error I get. Here's my |
Member
|
The issue happens with containerd. Thanks for sharing the |
Contributor
Author
|
@eddumelendez glad we figured it out 🙂 |
kiview
approved these changes
Sep 12, 2024
Contributor
Author
|
@eddumelendez is this okay to merge/release? |
Member
|
Thanks for your contribution, @monosoul ! |
fokion
pushed a commit
to fokion/testcontainers-java
that referenced
this pull request
Jan 18, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Given a Docker image that only has
linux/amd64as a platformWhen I try to pull it with testcontainers on an ARM Mac
Then I should be able to pull it without any problem
Current behavior:
Trying to pull such an image causes
com.github.dockerjava.api.exception.NotFoundException.If the image manifest in the registry doesn't contain the platform it is pulled for, the registry will return 404 with the following body:
{"message":"no match for platform in manifest: not found"}. Docker-java will throwcom.github.dockerjava.api.exception.NotFoundExceptionin such case (instead ofDockerClientException), so the fallback to x86 will never be attempted.This change fixes that. I didn't dig into how to write a proper test for that and I didn't find any tests covering the exception scenario, unfortunately. Nevertheless, this will make the fallback actually work, I built it locally with the patch and confirmed it works.
Fixes #9214