Arm unit tests should be created and hooked up to CI

[MichaelSimons]

This isn't trivial as there isn't an ARM SDK image therefore the current utest pattern doesn't work - use the platform SDK image to build an app that is tested with the platform runtime images.

[MichaelSimons]

In-lieu of having an ARM SDK, I think it would be reasonable to write a CI test that utilizes a multi-stage build running on a Windows 10 machine. The first stage would utilize an AMD64 SDK image to build an app that would get copied to the ARM Runtime image in a second stage (e.g. just like what is done in the dotnetapp-prod sample)

@ravimeda - Can you ensure the version of Docker on the CI machines supports multi-stage builds? I do not know what version of docker is on these machines. It would be valuable to emit this as part of the CI runs. If this is done for CI, the same should be done for official builds as well.

[ravimeda]

Thanks Michael. To get the version information of Docker where a test is running, I'm thinking of adding

$(docker version) | % { Write-Host "$_" }

at https://github.com/dotnet/dotnet-docker-nightly/blob/master/test/run-test.ps1#L45 Or the corresponding location in xUnit format of the tests. Thoughts?

[ravimeda]

17.05 or newer is required for multi-stage builds, per https://docs.docker.com/engine/userguide/eng-image/multistage-build/

[MichaelSimons]

I was thinking of adding it to the image-builder tool. Because of https://github.com/dotnet/dotnet-docker-nightly/issues/401, it would also need to be added to https://github.com/dotnet/dotnet-docker-nightly/blob/master/build-and-test.ps1 as this is currently the entrypoint for CI.

[MichaelSimons]

One more prereq that we need is a win 10 docker enabled machine in the CI pool. I am not sure if such a machine exists today.

[ravimeda]

@MichaelSimons please could you clarify the approach for ARM64 unit test.

In the first stage, create, build and publish a dotnet app on amd64 image. In the second stage, use a ARM32 image, copy the bits from first stage, and create an entry point to run the app. Based on that I have the Dockerfile shown below.

FROM microsoft/dotnet:2.0-sdk AS build-env

WORKDIR /app

RUN dotnet new console
RUN dotnet restore
RUN dotnet publish -c Release -o out
RUN ls -lR /app

# build runtime image
FROM microsoft/dotnet:2.0.0-runtime-stretch-arm32v7
WORKDIR appRuntime
COPY --from=build-env /app/out /appRuntime
RUN ls -lR /appRuntime
ENTRYPOINT ["dotnet", "app.dll"]

Build using the command below works fine, meaning no errors and a image named test is created. docker build -t test .

But running it throws an error as shown below -

docker run --rm --name app test
Did you mean to run dotnet SDK commands? Please install dotnet SDK from:
  http://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409

Why is SDK needed? To run the app, only runtime, which is already available on the image, is the only thing that is needed, right? Please clarify...

[ravimeda]

Interactively running it seems to work -

docker run --rm -it test
root@30386ccad8b7:/appRuntime# dotnet app.dll
qemu: Unsupported syscall: 389
Hello World!
root@30386ccad8b7:/appRuntime#

[MichaelSimons]

Per a discussion w/@ravimeda, the posted Dockerfile produces a working image. Not sure what caused the failure reported earlier.

[MichaelSimons]

To summarize - ARM utests have been created and are running as part of official builds. https://github.com/dotnet/dotnet-docker-nightly/issues/520 will cover CI.