You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Dominik Psenner <dp...@gmail.com> on 2017/07/09 15:37:29 UTC
[log4net] ci pipeline status update
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
Re: [log4net] ci pipeline status update
Posted by Dominik Psenner <dp...@gmail.com>.
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 <dp...@gmail.com>:
> 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
Re: [log4net] ci pipeline status update
Posted by Dominik Psenner <dp...@gmail.com>.
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" <dp...@gmail.com> 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" <dp...@gmail.com> 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
>>
>
Re: [log4net] ci pipeline status update
Posted by Dominik Psenner <dp...@gmail.com>.
Hi
I've just disabled both old build jobs in jenkins before they get on our
nerves. :-) Further I've updated the following files both to be in markup
and parts of their contents to reflect more the current state of the
project:
* README
* CONTRIBUTING
* ReleaseInstructions
Please note that ReleaseInstructions is merely there as a source of
information while we model the entire process in the cd-pipeline.
Contributing already contains the information of how it should be in the
future.
Cheers,
Dominik
2017-07-19 11:58 GMT+02:00 Dominik Psenner <dp...@gmail.com>:
> I have created this INFRA ticket regarding .net-2.0, node labels and the
> missing .net-3.5 on windows-2012-3:
>
> https://issues.apache.org/jira/browse/INFRA-14645
>
> 2017-07-19 10:54 GMT+02:00 Dominik Psenner <dp...@gmail.com>:
>
>>
>>
>> On 19 Jul 2017 6:35 a.m., "Stefan Bodewig" <bo...@apache.org> 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
>>
>>
>>
>
>
> --
> Dominik Psenner
>
--
Dominik Psenner
Re: [log4net] ci pipeline status update
Posted by Dominik Psenner <dp...@gmail.com>.
I have created this INFRA ticket regarding .net-2.0, node labels and the
missing .net-3.5 on windows-2012-3:
https://issues.apache.org/jira/browse/INFRA-14645
2017-07-19 10:54 GMT+02:00 Dominik Psenner <dp...@gmail.com>:
>
>
> On 19 Jul 2017 6:35 a.m., "Stefan Bodewig" <bo...@apache.org> 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
>
>
>
--
Dominik Psenner
Re: [log4net] ci pipeline status update
Posted by Dominik Psenner <dp...@gmail.com>.
On 19 Jul 2017 6:35 a.m., "Stefan Bodewig" <bo...@apache.org> 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
Re: [log4net] ci pipeline status update
Posted by Stefan Bodewig <bo...@apache.org>.
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.
> * 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.
Stefan
Re: [log4net] ci pipeline status update
Posted by Dominik Psenner <dp...@gmail.com>.
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 <dp...@gmail.com>:
> 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" <bo...@apache.org> 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
Re: [log4net] ci pipeline status update
Posted by Dominik Psenner <dp...@gmail.com>.
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" <bo...@apache.org> 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
>
Re: [log4net] ci pipeline status update
Posted by Stefan Bodewig <bo...@apache.org>.
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
Re: [log4net] ci pipeline status update
Posted by Dominik Psenner <dp...@gmail.com>.
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" <dp...@gmail.com> 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
>
Re: [log4net] ci pipeline status update
Posted by Dominik Psenner <dp...@gmail.com>.
>
> 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
Re: [log4net] ci pipeline status update
Posted by Dominik Psenner <dp...@gmail.com>.
2017-07-09 18:22 GMT+02:00 Stefan Bodewig <bo...@apache.org>:
> 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
Re: [log4net] ci pipeline status update
Posted by Stefan Bodewig <bo...@apache.org>.
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.
> 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