Alternatives that may allow us to do the same are gosu and su-exec. Note that sudo won't work.
On 10 Jul 2017 10:25 a.m., "Dominik Psenner" <[email protected]> wrote: > 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 >> >
