Re: [jira] [Resolved] (INFRA-14645) node requirements for jenkins job logging-log4net

[Dominik Psenner]

On 2017-08-29 16:12, Matt Sicker wrote:
I'm not too familiar with this area, but would using Windows containers
(e.g., via Docker or similar) work here? Or would that only support newer
versions of .net anyways?

Good idea Matt, unfortunately net-2.0 is not available in a windows 
server docker container as documented in the image variants section at 
https://hub.docker.com/r/microsoft/dotnet-framework/. Only 3.5 and newer 
are available. We already build net-3.5, net-4.0 and net-4.5 with 
jenkins. I've the impression that if we changed this today, we would 
gain nothing.


On 28 August 2017 at 23:32, Dominik Psenner <dpsen...@gmail.com> wrote:

Hi,

Chris just resolved our infra ticket regarding .net frameworks on the
windows nodes. This is a summary of the outcome:

Chris Thistlethwaite resolved INFRA-14645.
------------------------------------------
    Resolution: Fixed
1. We have observed that none of the windows nodes appear to have
net-2.0 installed so we cannot build assemblies against it. Is it possible
to install it on one or more of the windows nodes? It may well be the case
that it is not possible to have .NET framework 2.0 installed when a newer
.NET framework is installed on the same windows os.

1. All of the Jenkins Windows slaves have .Net 3.5 and .Net 2.0
installed, however in Server 2012 R2 .Net 2 is rolled up into 3.5. I'd also
argue that building for .Net 2 isn't something we can support if the tools
at hand only allow newer binaries.

To me this means that we can no longer build assemblies targeted against
the framework net-2.0. net-3.5 is the oldest we can get from jenkins. We'll
have to announce this soon.

2. We have observed that windows-2012-3 does not have .NET framework 3.5
installed while the other two Windows nodes have it installed.

2. jenkins-win2012-3 has been updated to fall in line with the other
nodes.

This means we will no longer see intermittent build failures because of the
missing framework.

3. As an improvement to the windows node labels we suggest to add
additional labels that match the installed .NET frameworks. Currently it is
rather unclear what the windows nodes actually can do and it would further
allow that not all windows nodes to have exactly the same components
installed. (i.e. windows-2012-1 could have the labels "Windows",
"dotnet-3.5", "dotnet-4.0", "dotnet-4.5", ..)

3. Agreed, the windows nodes could use more organized labeling, however,
we're currently keeping them all built out the same (or as close as
possible obviously) so we can maximize the few boxes we have. We just don't
have enough need to run specific Windows configurations.

Now that [2] is fixed, all windows nodes have the same capabilities and
therefore this is not an issue.

Cheers,
Dominik