Jenkins 2.248: Windows Support Updates

In theory, Jenkins can run everywhere where you can run Java 8 or Java 11, but, in practice, there are some limitations. The Jenkins core and some plugins contain native code, and hence they rely on operating systems and platforms. We use Java Native Access and Java Native Runtime libraries which provide wide platform support for low-level operations, but there are platform-specific cases not covered by such generic libraries. In the case of Windows platforms we use Windows Service Wrapper (WinSW) and Windows Process Management Library (WinP). These libraries depend on particular Windows API versions and, in the case of Windows services, on .NET Framework.

Historically Jenkins had no documented support policy for Windows, and we were accepting patches for all versions which existed since the Hudson inception in 2004. It became a serious obstacle for Windows component maintainers who had to be very conservative about incoming patches so that we could avoid breaking instances running on old platforms. Lack of testing for older platforms did not help either. And it is not just about maintenance overhead. Users were impacted as well, because it blocked us from adopting some new Windows features and making Jenkins more stable/maintainable on modern platforms.

To set proper expectations about Windows support, in the new policy we defined four support levels. See the Windows support policy page for the actual information about the support levels and the supported platforms. This blogpost captures the support state as of Jul 23, 2020:

When the policy was introduced, there were questions raised about platforms listed in the Level 3 support category. First of all, these platforms are still supported. Users are welcome to run Jenkins on these platforms. We recognize the importance of the platforms listed there, and we intend to keep compatibility with them. At the same time, particular functionality may break there due to the lack of testing when we update Jenkins or upstream dependencies. It may take a while until a fix is submitted by a user or contributor, because we do not maintain development environments for these platforms. By setting a Level 3 support level, we want to set an explicit expectation about those limitations.

If you are interested in expanding the official Windows support policy and adding more platforms there, we invite you to participate in quality assurance of Jenkins. You may contribute by expanding test automation for Jenkins, contributing test environments for your platforms, or participating in the LTS release candidate testing and reporting results. Please contact us via Platform SIG channels if you are interested.

Although the policy was introduced more than 1 month ago, Jenkins 2.248 is the first release where the new policy is applied. Starting from this release, we won’t support .NET Framework 2.0 for launching the Jenkins server or agents as Windows services. .NET Framework 4.0 or above is now required for using the default service management features.

This release also upgrades Windows Service Wrapper (WinSW) from 2.3.0 to 2.9.0 and replaces the bundled binary from .NET Framework 2.0 to 4.0. There are many improvements and fixes in these versions, big thanks to NextTurn and all other contributors. You can find the full WinSW changelog here, just a few highlights important to Jenkins users:

As you may see, there are many improvements available with this version, and we hope that it will make Windows service installation even more reliable. Some of the changes in WinSW also replaced old workarounds in the Jenkins core, making the code more maintainable.

We plan to continue expanding the Windows support in Jenkins, including providing official Docker images for newer Windows versions. For example, there is already a pull request which will introduce official agent images for Windows Server Core LTSC 2019 and for Windows Server Core and Nano Server 1909. We are also interested to keep expanding test coverage for Windows platforms. Any contributions and feedback will be appreciated!

We also keep working on improving Windows Services. Buddhika Chathuranga, a Google Summer of Code 2020 student, is working on support for YAML Configurations in Windows Service Wrapper, and on better verification of XML and YAML Configurations. See the details on the project page and in the Coding Phase 1 Report. In addition to that, there is ongoing work on a new Windows Service Wrapper 3.0 release which will redesign CLI and introduce a lot more improvements. If you are interested in contributing to Windows Service Wrapper, see the guidelines here. We will also appreciate your feedback on the WinSW Gitter channel.