1#!/bin/bash 2 3set -ex 4 5# go to the repo root 6cd $(dirname $0)/../../.. 7 8if [[ -t 0 ]]; then 9 DOCKER_TTY_ARGS="-it" 10else 11 # The input device on kokoro is not a TTY, so -it does not work. 12 DOCKER_TTY_ARGS= 13fi 14 15# First, build protobuf C# tests under x86_64 docker image 16# Tests are built "dotnet publish" because we want all the dependencies to the copied to the destination directory 17# (we want to avoid references to ~/.nuget that won't be available in the subsequent docker run) 18CSHARP_BUILD_COMMAND="dotnet publish -c Release -f net60 csharp/src/Google.Protobuf.Test/Google.Protobuf.Test.csproj" 19docker run $DOCKER_TTY_ARGS --rm --user "$(id -u):$(id -g)" -e "HOME=/home/fake-user" -e "DOTNET_CLI_TELEMETRY_OPTOUT=true" -e "DOTNET_SKIP_FIRST_TIME_EXPERIENCE=true" -v "$(mktemp -d):/home/fake-user" -v "$(pwd)":/work -w /work mcr.microsoft.com/dotnet/sdk:6.0.100-bullseye-slim bash -c "$CSHARP_BUILD_COMMAND" 20 21# Use an actual aarch64 docker image to run protobuf C# tests with an emulator. "dotnet vstest" allows 22# running tests from a pre-built project. 23# * mount the protobuf root as /work to be able to access the crosscompiled files 24# * to avoid running the process inside docker as root (which can pollute the workspace with files owned by root), we force 25# running under current user's UID and GID. To be able to do that, we need to provide a home directory for the user 26# otherwise the UID would be homeless under the docker container and pip install wouldn't work. For simplicity, 27# we just run map the user's home to a throwaway temporary directory 28CSHARP_TEST_COMMAND="dotnet vstest csharp/src/Google.Protobuf.Test/bin/Release/net60/publish/Google.Protobuf.Test.dll" 29docker run $DOCKER_TTY_ARGS --rm --user "$(id -u):$(id -g)" -e "HOME=/home/fake-user" -e "DOTNET_CLI_TELEMETRY_OPTOUT=true" -e "DOTNET_SKIP_FIRST_TIME_EXPERIENCE=true" -v "$(mktemp -d):/home/fake-user" -v "$(pwd)":/work -w /work mcr.microsoft.com/dotnet/sdk:6.0.100-bullseye-slim-arm64v8 bash -c "$CSHARP_TEST_COMMAND" 30