[BUG] stubb4j testcontainer failing with "exec /bin/sh: exec format error"

[oemergenc]

Describe the bug
Hi,

I am trying to use this docker image azagniotov/stubby4j:latest-jre21 with testcontainers to write integration tests. On my development machine (MAC M1) everything runs fine.
When I try to execute my test in a Github runner, the stubb4j based testcontainer fails to start.
See the log output of this run here:
https://github.com/oemergenc/spring-cloud-gateway-upgrade/actions/runs/8092179967/job/22112459714#step:4:1336

Please provide some basic information about you environment

• What is your OS: Windows/Mac/*Nix: MAC M1
• What is stubby4j version you are running: I am using this docker image azagniotov/stubby4j:latest-jre21
• Are you running stubby4j in Docker container or as a standalone JAR: Docker container
• If Docker container, what is the image tag: azagniotov/stubby4j:latest-jre21

YAML config

- web-socket:
    description: this is a web-socket config
    url: /demo/web-socket/1

    on-open:
      policy: once
      message-type: text
      body: successfully_connected
      delay: 200

    on-message:
      - client-request:
          message-type: text
          body: hello_request
        server-response:
          policy: once
          message-type: text
          body: hello_response
          delay: 250

      - client-request:
          message-type: text
          body: disconnect_request
        server-response:
          policy: disconnect
          message-type: text
          body: disconnect_response
          delay: 250

Expected behavior
The stubb4j testcontainer should start succesfully.

Additional context

[github-actions]

Thanks for opening your first issue. Pull requests are always welcome too! :)

[oemergenc]

I tried several images tags. This one seems to start successfully: azagniotov/stubby4j:latest-jre16

[azagniotov]

@oemergenc hi.

In your Ci, with regards to azagniotov/stubby4j:latest-jre21 , which architecture image are you also pulling down, is it the linux/amd64 or linux/arm64?

The azagniotov/stubby4j:latest-jre16 is a linux/amd64 one. Also, this older image was not built with Docker's BuildX plugin like the others more recent 🤔

[oemergenc]

Hi @azagniotov ,

I am using ubuntu-latest as my vm so I would assume that my CI uses linux/amd64 while my local Mac M1 uses linux/arm64. However, I am not specifying this explicitly, as far as a I know Docker should automatically understand which image architecture to pull with respect to the environment Docker is running on.

[azagniotov]

I understand what you are saying, I just wanted to confirm. I clearly remember that jdk16 image was the last image NOT built by Docker BuildX plugin … -Also, also what comes to mind that image does not have some of the more recent code updates… Thus, the “latest” tag is misleading  Maybe there is something related to BuildX that does not play well with test containers or something related to the more recent code changes… . I do have to apologize here, I am pretty busy these days with the day to day work and I don’t have time to deep dive into this at this point… I will try to go through the stack trace more closely, but if this is not related to the recent code changes, maybe I can try baking a recent image using one of the JDKs without leveraging BuildX and build an image just for one arch to test things out …On Feb 29, 2024, at 11:57, Oemer Genc ***@***.***> wrote: Hi @azagniotov , I am using ubuntu-latest as my vm so I would assume that my CI uses linux/amd64 while my local Mac M1 uses linux/arm64. However, I am not specifying this explicitly, as far as a I know Docker should automatically understand which image architecture to pull with respect to the environment Docker is running on. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[azagniotov]

But then, you say that locally things work fine for you. So I don’t know if baking a new image makes sense. Probably has to do with the Ci environment and  test containers. OR maybe how  the images are built using BuildX. Not sure On Feb 29, 2024, at 13:07, Alex Z. ***@***.***> wrote:I understand what you are saying, I just wanted to confirm. I clearly remember that jdk16 image was the last image NOT built by Docker BuildX plugin … -Also, also what comes to mind that image does not have some of the more recent code updates… Thus, the “latest” tag is misleading  Maybe there is something related to BuildX that does not play well with test containers or something related to the more recent code changes… . I do have to apologize here, I am pretty busy these days with the day to day work and I don’t have time to deep dive into this at this point… I will try to go through the stack trace more closely, but if this is not related to the recent code changes, maybe I can try baking a recent image using one of the JDKs without leveraging BuildX and build an image just for one arch to test things out …On Feb 29, 2024, at 11:57, Oemer Genc ***@***.***> wrote: Hi @azagniotov , I am using ubuntu-latest as my vm so I would assume that my CI uses linux/amd64 while my local Mac M1 uses linux/arm64. However, I am not specifying this explicitly, as far as a I know Docker should automatically understand which image architecture to pull with respect to the environment Docker is running on. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[oemergenc]

Yeah, the behavior is really strange. If you find time to look into it, that would be nice. For now we are using the jre16 version as this seems to work. I also want to say that we are also using docker buildx to build images and have good experience with it. Our own images are running fine on the CI server and also the local machines, so I would guess the problem might be in the build or the configuration of stubby4j and not in docker buildx.