Ok, the hack has its price. The uid is not always the same and therefore builds may randomly fail:
https://builds.apache.org/job/logging-log4net/view/change-requests/job/PR-8/9/console This is a call for help. Does anyone have a good idea how this issue can be solved for good? 2017-07-09 17:37 GMT+02:00 Dominik Psenner <[email protected]>: > Hi, > > 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: > > 1. a user with the jenkins uid did not exist within the docker container > 2. even if the user existed with the jenkins uid it cannot map to the > default home location of a user (/home/jenkins) because it is being > overridden when the docker container is run and the workspace is mounted > > So the solution was to create a user that has the uid and gid of the > jenkins user and let the home be not /home/jenkins but rather something > else. I decided that /var/workspaces/jenkins would do just like any other > place. > > Now on to the next issue: > > 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 > > Cheers > -- > Dominik Psenner > -- Dominik Psenner
