hydra-import Dockerfile in testsuite contains hardcoded reference to hydra binary

[Rishi Misra]

I was trying to run integration tests on s390x architecture and noticed that hydra-test failed. After some investigation I found that this was caused due to incompatible strimzi-oauth-testsuite/hydra-import image generated by the build step.

It turns out that hydra-import Dockerfile downloads x86 version of hydra_1.0.0_Linux_32-bit.tar.gz which causes problems on s390x architecture.

I made following changes to make it work on s390x arch and think it may also work on x86 arch. All I am doing here is to compile hydra from source instead of downloading a specific version:

index 6d6e0f2..8de6f6e 100644
--- a/testsuite/docker/hydra-import/Dockerfile
+++ b/testsuite/docker/hydra-import/Dockerfile
@@ -1,10 +1,15 @@
 FROM alpine

-RUN apk add -U --no-cache bash ca-certificates curl \
-    && mkdir /tmp/hydra \
-    && cd /tmp/hydra \
-    && wget -q https://github.com/ory/hydra/releases/download/v1.0.0/hydra_1.0.0_Linux_32-bit.tar.gz \
-    && tar xvzf hydra_1.0.0_Linux_32-bit.tar.gz \
-    && cp hydra /usr/bin/ \
+COPY --from=golang:1.16-alpine /usr/local/go/ /usr/local/go/
+ENV PATH="/usr/local/go/bin:${PATH}"
+
+RUN apk add -U --no-cache bash ca-certificates curl git make gcc musl-dev \
+    && cd /tmp \
+    && export GOPATH=/opt/go/ \
+    && git clone -b v1.8.5 https://github.com/ory/hydra.git \
+    && cd hydra \
+    && GO111MODULE=on make install-stable \
+    && cp $GOPATH/bin/hydra /usr/bin/ \
     && cd \
     && rm -rf /tmp/hydra
+ENV GODEBUG=x509ignoreCN=0

Please let me know if this is an acceptable solution and whether Dockerfile can be changed accordingly.

Thanks.

[Jakub Scholz]

I leave it to @mstruk ... but I think it would be better to download different binary then build the project our self.

[Marko Strukelj]

Building Hydra from source as part of the testsuite run sounds like it would take too much time - running the testsuite already takes a long time as it is.

Ideally we build the Hydra binary separately as @scholzj suggested. We can add it to the Github repo and use that instead of the upstream Hydra release binary on s390x.
Or the build from source could only be done on s390x.

There could be a separate Dockerfile for s390x.

[Rishi Misra]

Thanks @mstruk and @scholzj for quick reply!

Currently Hydra does not produce s390x binary in the Release page. I am happy to try any approach that will help with making testcase easier to run on s390x. A generic/plugin solution would be preferable in case future archs are added to the test framework.

Should I use a new Dockerfile for s390x is there a way to control the build/test to use this Dockerfile instead? Perhaps something that can be passed on the mvn clean install or mvn clean install -f testsuite command?

Thanks.

[Rishi Misra]

@mstruk @scholzj just wanted to follow-up on this one - do you have a preference? Tx.

[Marko Strukelj]

@rposts There are profiles defined in testsuite pom.xml. You could maybe add another one. But I'm not sure that's the way to go. Ideally the build determines at runtime the environment where it is running and uses a different config or artifacts accordingly. In testsuite there are profiles defined and maybe it's possible to add one that is s390x specific and define activation rule that only activates it in s390x environment. It could specify properties like the special docker image to use ...
But it's hard to say what the most elegant way is without actually putting some solution together.

[Rishi Misra]

@mstruk - I have initiated a #144 to address this issue. Let me know if it looks ok. Thanks!

[Rishi Misra]

Closing as #144 has been merged. Thanks!