I just stumbled upon this which may allows us to detect the expected uid that a docker container is run in when the docker container is built. We can use that information to prepare the docker container user so that its uid and gid match the one we need later when the docker container is run:
https://github.com/bdruemen/jenkins-docker-uid-from-volume/blob/master/Dockerfile On 9 Jul 2017 7:10 p.m., "Dominik Psenner" <[email protected]> wrote: > dotnet test inside of the directory is what I've done so far. >>> >>> Stefan >>> >> >> I'm adding dotnet test into the jenkinsfile. We'll see what happens. :-) >> > > This is the outcome. So something works, but I see no tests and a strange > warning. > > {quote} > > [log4net_feature_cd-pipeline-76KUCPODUF6LCE45226EBUR4GNVLYPMYVC23Z4ITBOMNJT3CA2WA] > Running shell script > + cd netstandard/log4net.tests > + dotnet test > Build started, please wait... > /usr/share/dotnet/sdk/1.0.4/Microsoft.Common.CurrentVersion.targets(1964,5): > warning MSB3277: Found conflicts between different versions of the same > dependent assembly that could not be resolved. These reference conflicts are > listed in the build log when log verbosity is set to detailed. > [/home/jenkins/jenkins-slave/workspace/log4net_feature_cd-pipeline-76KUCPODUF6LCE45226EBUR4GNVLYPMYVC23Z4ITBOMNJT3CA2WA/netstandard/log4net.tests/log4net.tests.csproj] > Build completed. > > Test run for > /home/jenkins/jenkins-slave/workspace/log4net_feature_cd-pipeline-76KUCPODUF6LCE45226EBUR4GNVLYPMYVC23Z4ITBOMNJT3CA2WA/netstandard/log4net.tests/bin/Debug/netcoreapp1.0/log4net.tests.dll(.NETCoreApp,Version=v1.0) > Microsoft (R) Test Execution Command Line Tool Version 15.0.0.0 > Copyright (c) Microsoft Corporation. All rights reserved. > > > Starting test execution, please wait... > {/quote} > > It may well be that since our tests are just included in this test > project, they are simply not detected by "dotnet test" because the wrong > test runner is used. We further need a nant target for this. > > I further noticed just now that we only test the debug assemblies and I > suggest that we also test the built release assemblies? At the moment > nobody would notice if there was an #ifdef or code optimization glitch > somewhere that is only present in the release assemblies. :-( > -- > Dominik Psenner >
