2018-01-13 16:40 GMT+01:00 Stefan Bodewig <[email protected]>: > On 2018-01-12, Dominik Psenner wrote: > > > I'm working on LOG4NET-566, hoping that we can get a release build > > from our CI. > > CI won't be able to create the oldkey binaries unless we are willing to > make the old key public (which defeats the reason why the new key was > introduced in the first place. >
That's not necessarily true. There are ways to inject confidential information into the CI pipeline. Still, everyone having access to the jenkins configuration may get hold of the private key, though. We still have to option to not build the old key binaries any longer or build them manually and add them to the release during the release process. > > > The build currently gets stuck because of an unknown reason. It would > > be great to get some help on finding out why the heck the > > netstandard-1.3 tests behave as they do here: > > Currently I'm not able to build .NET Standard 1.3 at all, I'll need to > create a new VM for that, I guess. The zoo of infrastructure needed to build a log4net release is insane. > All my .NET Standard builds have > happened on Windows in the past, maybe the issue you see is specific to > Linux? > If that's the case, the situation is even worse than I hoped it would be. This would mean that the log4net binaries that should support netstandard-1.3 do not work as they should when run on linux. We probably should run the netstandard tests both on windows and linux to know more. The jenkins pipeline allows us to do so. It is a matter of adding a new stage to the build pipeline. -- Dominik Psenner
