2017-07-09 18:22 GMT+02:00 Stefan Bodewig <[email protected]>: > On 2017-07-09, Dominik Psenner wrote: > > > I finally managed to build the netstandard assemblies in our jenkins > > pipeline. It was a tough task and the solution feels like a hack, but it > > works. See: > > > https://builds.apache.org/job/logging-log4net/job/develop/ > > > The problem was that dotnet always attempts to find and store dependent > > assemblies in the users home directory, which obviously failed for > several > > reasons > > would an explicit --packages to "dotnet restore" help? I haven't tried > it myself. >
Unfortunately not. Also setting $HOME to something else did not work as expected. It did also not help to write an extensive NuGet.Config file because dotnet would attempt to write to / anyway. The only solution so far is to add a user that has the uid that jenkins is going to pass in to docker with -u: $ docker run -t -d -u 10025:12040 -w /home/jenkins/jenkins-slave/workspace/log4net_f[...] Given that the user uid is not known when the docker container is created (because it is still executing as user root), I just tried now to run groupadd and useradd in the stage by installing sudo in the docker container and let everyone do "sudo useradd" and "sudo groupadd". This was the outcome: + sudo groupadd -r -g 12040 jenkins-slave sudo: unknown uid 10025: who are you? :-( Please note that using a customWorkspace did not help either because then the Dockerfile cannot be resolved anymore. > > > I tried to run the tests against the built netstandard assemblies but > while > > doing so I noticed that there is no nant target for it, nore a > > documentation on how the test project can be run. Does anyone out there > > know the best practice on how to run the tests included in this project? > > > log4net/netstandard/log4net.tests/log4net.tests.csproj > > 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. :-) -- Dominik Psenner
