On 19 Jul 2017 6:35 a.m., "Stefan Bodewig" <[email protected]> wrote:
On 2017-07-18, Dominik Psenner wrote: > 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. Wow, congrats. Many thanks for your persistence. > 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) It may happen that it's not possible to install 2.0 once a more recent framework is there, I'm not sure. If thats the case then net-2.0 may be installed on windows-2012-3. Gotta verify that. In any case it would be sensible if infra would add additional labels on jenkins nodes so that the labels reflect the nodes' capabilities. Something like dotnet-4.5, dotnet-4.0, dotnet-3.5, ... What do you think? > * 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) +1 for removing the old build. We still have to find and fix what's causing the old test job to fail, though. Stefan
