Hi, oohh how I like to be the bringer of good news! Right now I was finally able to fix the building of the netstandard target by providing a jenkinsfile script that detects the UID and GID of the working path and passing that in as parameters into the builder-netstandard dockerfile when it is built. That dockerfile then creates a user with that UID and GID such that the nant executable finds a place to store its cached assemblies and what else it needs.
I pushed those changes to all branches except master to see how it behaves and it's looking great! *yay!* The following todos are yet to complete before building and testing the assemblies is ok: * node 'windows-2012-3' [1] lacks the installation of .net framework 3.5 whereas 'windows-2012-1' [2] and 'windows-2012-2' [3] have it (probably needs to be fixed by INFRA) * build and test assemblies for net-2.0 (probably needs to be fixed by INFRA by installing that on the windows nodes) * verify and probably fix testing of the assemblies for target net-standard * parse the test results when testing net-standard * the old build job can probably safely be disabled/removed because the new pipeline does the same builds and regression tests and even more (please discuss) Last but not least we have a few things we definitely have to look at: * there are flaky tests (currently 6 out of ~1400) [4] Cheers! [1] https://builds.apache.org/job/logging-log4net/job/feature%252FRollingFileAppender-NG/8/console [2] https://builds.apache.org/job/logging-log4net/job/feature%252Fcd-pipeline/156/consoleFull [3] https://builds.apache.org/job/logging-log4net/job/feature%252FRollingFileAppender-NG/8/console [4] https://builds.apache.org/job/logging-log4net/job/feature%252Fcd-pipeline/156/testReport/log4net.Tests.Appender/ 2017-07-10 13:47 GMT+02:00 Dominik Psenner <[email protected]>: > If this was not about hacking it would be a lot easier to accomplish. 😁 > > I found also out that it is good practice to add arguments to the > dockerfile. This would then be the interface to pass in environment > variables of jenkins. A good candidate could be WORKSPACE and extract uid > and gid inforation from there. > > Last but not least, we could patch and fix the dotnet cli tool to not > require a valid user in the docker container... > > On 10 Jul 2017 10:33 a.m., "Stefan Bodewig" <[email protected]> wrote: > >> On 2017-07-10, Dominik Psenner 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 >> >> looks like an intersting hack :-) >> >> Stefan >> > -- Dominik Psenner
