Adapt OperatingSystemEndOfLifeAdminMonitorTest for Ubuntu 22.04
Ubuntu 22.04 is end of life April 1, 2027. That means we are now
within the 6 month end of life warning window for the operating system.
That causes the test to fail on ci.jenkins.io because it is using Ubuntu
22.04 agents.
Temporarily adapt the expected values in the tests for Ubuntu 22.04.
Those changes can be removed when the agents on ci.jenkins.io are running
a newer operating system. Refer to help desk:
* https://github.com/jenkins-infra/helpdesk/issues/5124
Testing done:
* Confirmed tests fail on Ubuntu 22.04 without this change
* Confirmed tests pass on Ubutnu 22.04 with this change
LTS RPM file names follow the same naming pattern as weekly now.
Testing done:
* Confirmed that the action to upload 2.580.1 LTS failed for the RPM file.
* Downloadedd the 2.580.1 LTS binary locally using the weekly file pattern
* Drop support for remoting releases before 2024-08
* Adapt Security3430Test to latest changes
Uses the original changes from @daniel-beck, merged with master branch.
One relevant change for discussion is the switch from IllegalStateException
to IOException in the assertions in the _run method. I believe that is the
correct change, but would like validation from @daniel-back to be certain.
- assertThat(itex.getCause(), instanceOf(IllegalStateException.class));
+ assertThat(itex.getCause(), instanceOf(IOException.class));
Testing done:
* Confirmed Security3430Test passes in my development environment
---------
Co-authored-by: Daniel Beck <daniel-beck@users.noreply.github.com>
Co-authored-by: Daniel Beck <1831569+daniel-beck@users.noreply.github.com>
* Use assertions in test body instead of assumptions in SlaveTest
Failed assumptions silently ignore the test
Failed assertions call us to immediate action
* Use assertEquals instead of assumeTrue in ArgumentListBuilder2Test
* Use assertFalse, not assumeFalse in UpdateCenterPluginInstallTest
Fail the tests if updates.jenkins-ci.org cannot be resolved rather than
quietly skipping the tests. If our tests need to be resilient to DNS
lookup failures, there are many other places that need to be changed.
* Assert rather than assume white listed classes include LinkedListMultimap in ClassFilterImplTest
* Remove assume that checked if tests are running in Jetty servlet context in SystemPropertiesTest
Tests always run with Jetty servlet context.
* Replace assume with assert in FilePathTest
If the assumption were not satisfied, the test would be skipped insted
of failing.
Better to fail the test explicitly than to quietly skip the test and
rely on review of the results to detect the test was skipped.
Testing done:
* Confirmed the test continues to pass
OpenSSF scorecard incorrectly reports that Jenkins releases are not signed
because we upload the release war file without uploading a matching GPG
signature file. The GPG signature file is available from get.jenkins.io
and its use is documented at https://www.jenkins.io/download/verify/
Extends the GitHub action that publishes release artifacts to publish the
jenkins.war.asc file at the same time that it publishes the jenkins.war
file.
The OpenSSF scorecard data is available from:
* https://api.securityscorecards.dev/projects/github.com/jenkinsci/jenkins
The multiline syntax for the gh-release action is documented at:
* https://github.com/softprops/action-gh-release#%EF%B8%8F-uploading-release-assets
Testing done:
* Executed the `wget` command locally to confirm the '.asc' file is available
* Remove XStream2EncodingTest, all tests are skipped
Tests are skipped on all platforms and on all currently support JDK's
(21 and 25) because the tests were only run when the JVM default character
set was ISO-8859-1. Java 21 uses UTF-8 as its default character set.
If we want to restore the test, we'll need to adjust the `--add-opens`
configuration of Jenkins core. Test is not valuable enough to justify
that change.
Testing done:
* Confirmed with ci.jenkins.io results that all tests are skipped
* Confirmed working in pull request:
https://github.com/jenkinsci/jenkins/pull/27248
* Confirmed working on my Linux computer
* Confirmed working on my Windows agents
* Use UTF-8 character set in HierarchicalStreamWriter
JDK 21 and JDK 25 both use UTF-8 as their default character set on all platforms.
Resolves a review comment by removing the XStream2EncodingTest reference
Testing done:
* Confirmed that all XStream2 tests continue to pass
* UTF-8 is the default encoding - update toXML Javadoc to match
Amends pull request:
* https://github.com/jenkinsci/jenkins/pull/27038
Without this change, the "Manage Jenkins" / "Security" page fails to
open and reports that the config.jelly cannot be parsed.
Jenkins 2.573 did not include the pull request. I seem to have merged
it after the 2.573 build started.
Testing done:
* Confirmed that "Manage Jenkins" / "Security" on Jenkins 2.573 opens successfully
* Confirmed that "Manage Jenkins" / "Security" on master branch does not open
* Confirmed that "Manage Jenkins" / "Security" opens successfully with this change
* Stop signing the war file with jarsigner
The Jenkins code signing certificate that was issued by Digicert in 2023
will expire May 16, 2026. The replacement code signing process is able
to sign MSI installer files, but is not able to sign war files and other
Java objects.
The Jenkins war file will continue to be signed with the GPG private key
of the Jenkins project. Detailed instructions to verify the signing
of the Jenkins war file are included in the Jenkins documentaiton at
https://www.jenkins.io/download/verify/
A SHA-256 checksum is also provided for the Jenkins war file to further
assure there has been no data corruption or tampering with the contents
of the war file.
https://github.com/jenkins-infra/helpdesk/issues/4923 is the Jenkins
infrastructure help desk ticket that tracks the update of the MSI code
signing process.
Testing done:
* Confirmed that compilation works as expected
* Confirmed that all tests continue to pass after this change
* Remove unreferenced dummy.keystore
* Skip symlink tests on Windows developer machines
Windows does not support symbolic links by default. Tests fail for new
contributors on Windows if they do not adjust their Windows configuration
to allow symbolic links.
We don't want to require that developers running on Windows must enable
symbolic links. We want to always run the tests on Windows machines in
our CI environment.
Amends pull request:
* https://github.com/jenkinsci/jenkins/pull/26203
New tests that depend on Windows symbolic links were added as part of
the core tests for SECURITY-3657 in commit 6dc9993760. The technique
from pull request 26203 is too complicated for use in multiple modules.
This change simplifies the logic by not attempting to detect if symlinks
are supported on the Windows computer running the tests. Since the full
set of automated tests of Jenkins core require many hours to complete
on Windows, it seems safe to assume that developers on Windows will not
mind skipping the tests that require symlinks.
Testing done:
* Confirmed tests pass on Linux
* Confirmed tests are skipped on Windows computers that are not CI agents
* Confirmed tests pass on Windows computers that are CI agents
* Disable symlink tests with a Maven profile
The profile will disable symlink tests on Windows unless the CI
environment variable is set.
The https://github.com/release-drafter/release-drafter/pull/1475 breaking
changes section for release drafter 7.0.0 says:
If you were using a specific access token using env.GITHUB_TOKEN:
$MY_CUSTOM_TOKEN, migrate to the new token: input
jobs:
steps:
# Before
- uses: release-drafter/release-drafter@v6
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
# After
- uses: release-drafter/release-drafter@v7
with:
token: ${{ secrets.GITHUB_TOKEN }}
The certificate in the test source code expired Feb 20, 2026 and I was
unable to find the correct steps to regenerate the certificate and the
matching platform-plugins.json file.
Rather than block other pull requests because the test is failing on
the master branch, let's disable the test.
Testing done:
* Confirmed that the test fails without this change
* Confirmed that the test passes with this change
* Attempted to create a new certificate as demo.crt based on the comments
at the end of the source file, but was unable to create the correct
platform-plugin.json file to use the new demo.crt
* Do not run symlink tests on Windows if symlinks are not supported
Windows does not support symbolic links by default. Tests fail for new
contributors on Windows if they do not adjust their Windows configuration
to allow symbolic links.
* Fast incremental build
* Create a symbolic link on Windows to confirm they are supported
* Fix the copyright year - 2026
GitHub Copilot caught the mistake
* Remove a white space change
* Revert "Fast incremental build"
Don't change production
This reverts commit 0750dd8bc5.
* Fail tests on CI if Windows symlinks are not enabled
We do not want to fail the test on a developer computer if symlinks are
not enabled, but we do want to fail the test if a CI agent on Windows
does not have symbolic links enabled.
* Remove noisy test logging from QueueTest
No one is reading the test logs. They add megabytes to the output and
may obscure useful messages.
* Stop and delete builds 1 and 2 in QueueTest to prevent Windows test failures
The Windows file system prevents cleanup of the builds and jobs directory
while the test has them open. Stopping the builds and deleting them is
enough to close the directory and allow it to be deleted.
Testing done:
* Before this change, testGetCauseOfBlockageForNonConcurrentFreestyle
failed in about 50% of runs on my 7 different Windows agents
* After this change, testGetCauseOfBlockageForNonConcurrentFreestyle
passes all runs on my 7 different Windows agents
Fixes#26088
The user interface update to the Credentials plugin in pull request:
* https://github.com/jenkinsci/credentials-plugin/issues/990
removed the image that this test used for its initial configuration.
The change was released in Credentials plugin:
* https://github.com/jenkinsci/credentials-plugin/releases/tag/1460.v48765a_c7d849
The new release of the Credentials plugin was included in Jenkins core
with pull request:
* https://github.com/jenkinsci/jenkins/pull/26046
This change switches from the Credentials plugin to the Matrix Project
plugin as the base for the test. The assumption is that user interface
changes are less likely to the Matrix Project plugin.
Testing done:
* Confirmed that the tests fail on Windows without this change
* Confirmed that the tests pass on Windows with this change
Warn users of Java 25 end of support September 2029
Beginning in March 2029, users will be warned that Java 25 will be
reaching its end of support in the Jenkins project.
Amends pull request:
* https://github.com/jenkinsci/jenkins/pull/11148
The 2+2+2 Java support plan recommends that we drop support for a Java
line after two years so that we're only supporting two Java versions at
a time. Refer to the blog post:
* https://www.jenkins.io/blog/2023/11/06/introducing-2-2-2-java-support-plan/
Also refer to the Jenkins Enhancement Proposal pull request (incomplete):
* https://github.com/jenkinsci/jep/pull/400
Testing done:
* None. Relying on the existing behavior that I've seen from the Java
17 administrative monitor. It is now shown to users to warn them that
we plan to drop Java 17 support by the end of March 2026
[JENKINS-76295] Revert "Update dependency commons-io:commons-io to v2.21.0 (#11276)"
https://issues.jenkins.io/browse/JENKINS-76295 reports that SSH build
agents fail to connect after this change was included.
Testing done:
* Confirmed that Jenkins 2.537 fails to start an SSH build agent on
Debian 13
* Confirmed that with this change reverted, the SSH build agent starts
as expected on Debian 13
This reverts commit ab45729395.
The weekly release of Jenkins 2.536 failed its initial build because Maven
release plugin 3.2.0 behaves differently than Maven release plugin 3.1.1.
For 2.535, we were using Maven release plugin 3.1.1 and it did not require
that we skip spotless verification during the `release:prepare` phase.
Maven release plugin 3.2.0 requires it.
Will allow the temporary change to be reverted from pull request:
* https://github.com/jenkins-infra/release/pull/782
Special thanks to @jglick for noting the better way to resolve the issue.
Testing done:
* Confirmed that builds fail without this change when running
`mvn -B -V -ntp release:prepare`
* Confirmed that builds pass with this change when running
`mvn -B -V -ntp release:prepare`
* Launchable rejects a name with embedded '%2F'
The '%2F' is a URL encoded '/' and occurs when a branch name with a '/'
is pushed to the Jenkins core repository.
This first step in the fix is to show that the bug exists.
* Sanitize launchable build name
Test was slightly flaky before ci.jenkins.io transitioned from Azure to
AWS agents. Since the transition, the test fails much more frequently.
The failures are not pointing to a real problem, but a change in the
infrastructure.
Infra help desk issue that is investigating:
* https://github.com/jenkins-infra/helpdesk/issues/4730
Let's not waste resources running this test on Windows in CI.
Testing done:
* Ran JenkinsTest#runScriptOnOfflineComputer on 5 different Windows
computers before making this change. Execution times ranged from
21 sec to 45 sec (depending on the age of the Windows computer).
None of those tests failed.
* Confirmed that the test is skipped on those Windows computers after
making this change
Those Windows computers are running a mix of Windows 10 and Windows 11
with local SSD disc drives. They each have at least 16 GB of RAM.
* Accept UserIdCause or LegacyCodeCause in disconnectCause test
The hudson.model.ExecutorTest.disconnectCause() test fails in up to 10%
of jobs on ci.jenkins.io because the cause is a LegacyCodeCause instead
of the expected UserIdCause.
In my 140 runs on my local Linux computer, I never saw a LegacyCodeCause,
but it seems safe to check one of two failure messages rather than fail
the test.
* Fix compilation error
* Fix FileChannelWriterTest by reverting to JUnit 4
Test does not fail on my local Windows computer with JUnit 5 or with
JUnit 4. Reverting this to see if it resolves the issue so that other
pull requests will not be blocked by the failing test.
* Fix VirtualFileTest by reverting back to JUnit 4
(cherry picked from commit dc3ae003fb)
* Revert "[JENKINS-75465] Delete RunIdMigrator as it has been 10 years since this migration"
* Fast incremental build
* Revert "Fast incremental build"
Leave the commit as only the revert of the original change
This reverts commit 2cf37a11df.
---------
Co-authored-by: Kris Stern <krisstern@outlook.com>
The checkstyle warning fails the build and reports that the line is
longer than 240 characters. Break the line on the sentence boundary
so that it is less than 240 characters.
Detected by running:
mvn -am -pl war,bom -Pquick-build clean install
mvn javadoc:javadoc
The tests have failed consistently on Windows agents of ci.jenkins.io
since we switched to virtual machines instead of containers. The tests
fail on the stable-2.479, stable-2.492, and master branches. The tests
do not fail when run on my Windows 10 and Windows 11 computers in my
home lab.
Needs more investigation, but I would rather not block the 2.492.1
release candidate build for that investigation.
The issue submitter suggested that the plugin incompatibility message
would be clearer if it specifically referred to the installed version
of the plugin. That seems like an easy change to make and if it helps
a few users, that is great.
Also update the end of life dates for other operating systems based on
https://endoflife.date/ data.
Removes the 'start' entries because we are past the end of life date
of the RHEL 7 derivatives and the one other start date is not needed
because the default start date will cover it correctly.
Confirmed with a CentOS 8 computer that the end of life message
is displayed with the correct date for the CentOS 8 end of life.
The corrected end of life date has already passed, so there may be
Jenkins users that are surprised when their next upgrade reports that
they are running an unsupported operating system.
When the Jira issue is included in the changelog summary, it is included
in the generated changelog as the initial text of the changelog entry.
The same issue link is then included by the changelog generator at the end
of the changelog description. Remove the example that places the issue at
the start of the changelog text and explain that the issue link should be
elsewhere in the pull request so that the changelog generator can use it.
When the Jira issue is included in the changelog summary, the changelog
maintainers must remove it before the changelog is published. It is
better to not include the Jira issue in the changelog summary so that
changelog maintainers do not need to remove it.
Remind submitters that they should not delete the upgrade guidelines
section because the presence of the upgrade guidelines section is used
by the changelog generator as the terminator for the proposed changelog
entries.
Several of the changes are not detected by the Python script but were
detected by `git grep TODO | grep since` with review of the output.
The cases that are not detected by the Python script seem obscure enough
to not bother with additions to the script. If they become common
practice, then we can extend the Python script.
Remove SECURITY-2481 escape hatch
https://www.jenkins.io/security/advisory/2021-10-06/#SECURITY-2481 was
published in October 2021 with an escape hatch that allows users to
enable the path traversal vulnerability on Windows. Jetty 12 detects
the vulernability even before the request reaches Jenkins and returns
an HTTP error, as required by the Servlet API specification.
Remove the escape hatch because the escape hatch is intended to be
temporary and we don't want to reimplement the escape hatch within
Jetty configuration.
https://issues.jenkins.io/browse/JENKINS-73129 includes further discussion
of the alternatives.
Return to the Java 11 end of life date of 30 Sep 2024 for the LTS lines
rather than changing it to match the expected 30 Oct 2024 release date
of the first LTS to require Java 17.
Little benefit to LTS users to extend the end of life message until end of October.
Changing the date will cause the administrative monitor to reappear.
Better to leave it hidden if they have decided to hide it.
Alert Java 11 users of 18 Jun 2024 end of life in weekly
Also updates the Java 11 end of life date for Java 11 users running with
the long term support release.
Add end of life data for several more Linux releases
Adds data for:
* Alpine Linux 3.19
* Amazon Linux 2 (already end of life for Jenkins)
* Amazon Linux 2023
* Fedora 39
Includes test data for more Linux operating systems that were already
included in the end of life data.
* [JENKINS-72469] Avoid repeated tool downloads from misconfigured HTTP servers
The Azul Systems content delivery network stopped providing the
last-modified header in their URL responses. They only provide the
ETag header.
Add ETag support to the Jenkins FilePath URL download method so that if ETag is
provided, we use the ETag value. If last-modified is provided and matches, we
continue to honor it as well.
https://issues.jenkins.io/browse/JENKINS-72469 has more details.
https://community.jenkins.io/t/job-stuck-on-unpacking-global-jdk-tool/11272
also includes more details.
Testing done
* Automated test added to FilePathTest for code changes on the controller.
The automated test confirms that even without a last-modified value,
the later downloads are skipped if a matching ETag is received.
The automated test also confirms that download is skipped if OK is
received with a matching ETag. No automated test was added to confirm
download on the agent because that path is not tested by any of the
other test automation of this class.
* Interactive test with the Azul Systems JDK installer on the controller.
I created a tool installer for the Azul JDK. I verified that before
this change it was downloaded each time the job was run. I verified
that after the change it was downloaded only once.
* Interactive test with the Azul Systems JDK installer on an agent.
I created a tool installer for the Azul JDK. I verified that before
this change it was downloaded each time the job was run. I verified
that after the change it was downloaded only once.
* Interactive test on the controller with a file download from an NGINX
web server confirmed that the tool is downloaded once and then later
runs of the job did not download the file again.
* Use equals instead of contains to check ETag
Don't risk that a substring of an earlier ETag might cause a later
ETag to incorrectly assume it does not need to download a modified
installer.
* Use weak comparison for ETag values
https://httpwg.org/specs/rfc9110.html#field.etag describes weak comparison
cases and notes that content providers may provide weak or strong entity
tags. Updated code to correctly compare weak and strong entity tags.
Also improves the null checks based on the suggestions from @mawinter69
in https://github.com/jenkinsci/jenkins/pull/8814#discussion_r1438909824
* Test comparison of weak and strong validators
* Do not duplicate test args, more readable
* Use better variable names in test
Cover more branches in the equalEtags method as well
* Fix variable declaration order
Show Java version admin monitor at 12 months and 3 months
Daniel Beck described his recommendation to alert users at 12 months
and at 3 months prior to the end of support of a Java version.
He wrote:
> The second warning in particular needs to strike a balance between
> being shown late enough so it's actually relevant for whoever hasn't
> acted yet, while being shown early enough that slightly more elaborate
> environments (difficult to schedule maintenance windows) are informed
> in time. 3 months aligns rather nicely with the LTS schedule where
> we kinda expect folks to do that anyway.
>
> 18/9, or even 12/6 errs too far on the side of those for whom this is
> extreme effort (and who dismissed the first message more appropriate for
> their environment!), while showing everyone else completely irrelevant
> notices they won't care about for many months to come.
https://github.com/jenkinsci/jep/pull/400#discussion_r1371510566 provides
more details.
The Java 8 to Java 11 transition saw a significant change in adoption of
Java 11 once the admin monitor was visible to users. That was shown
slightly over 12 months before the release that required Java 11.
This change continues that pattern of 12 months warning before end
of support.
https://github.com/jenkinsci/jep/pull/400#discussion_r1375623888 has a
graph that shows the adoption curves for Java 8, Java 11, and Java 17.
Remember the lines that were read from the file and the last file that was
read so that the next iteration can reuse the data that was already read.
No need to read `/etc/os-release` once for each entry in the JSON file.
The contents of the file won't change from the first entry to the last
entry in the JSON file.
This won't change much, since the read operation is probably already
cached by the operating system with a file as small as `/etc/os-release`.
Cached file content is deleted at the end of the loop over the JSON file.
Since the transition to systemd, we no longer read the contents of
/etc/sysconfig/jenkins on Red Hat Enterprise Linux systems. The changes
that a user can make with systemd are either modifying the environment
variable or they are modifying a Java property. Since those two cases
are already covered, let's not mention the different ways of starting
the controller.
We don't actively promote the use of alternate web containers and
setting the environment variable in the web container admin tool is
already covered by the simpler statement that the environment variable
needs to be set.
We absolutely should not suggest that they modify the contents of the
jenkins.war file. That type of change will likely be erased on the
next upgrade.
https://github.com/jenkins-infra/jenkins.io/pull/6409 review process
showed this issue.
GitHub task lists do not support indented lists yet
When I submitted https://github.com/jenkinsci/jenkins/pull/8118 , the
task list failed to render until I removed the indented list item
* Ubuntu 18.04 end of life admin monitor
First prototype that includes a user interface and localized messages
with parameters to support the specific operating system.
* Use a base class for common features
Admin monitors are disabled and enabled by a user interface action.
There is not an obvious way to detect that a date has passed so that it
should be enabled again.
* Better comment
* Make the logging clearer
* Split pattern check to separate method
* Add a message to show after end of life
* Suppress most logging
* Minor logging improvements
* Use actual end of life date for Ubuntu 18.04
* Logger not needed
* Add Alpine 3.14 end of life admin monitor
* Add Alpine 3.15 end of life monitor
* Add Alpine 3.16 end of life monitor
* Add Alpine 3.17 end of life monitor
* Spotless cleanup
* Add Fedora 37, 38, and Red Hat 7
* More accurate regex to detect version
* Add Debian 10 end of life admin monitor
* Add a few tests
* Add another test
* Fix checkstyle violations
* Fix spotbugs warning
* Correct the copyright
* Make test viable on non-Linux machines
Do not depend on the existence of /etc/os-release
* Name the setup function more accurately
* Test a file with non-matching content
* Test the Alpine end of life admin monitors
* Add more tests
* Test Fedora 37 admin monitor
* Add RHEL 7 test
* Announce RHEL 7 early end of support immediately
* Use consistent logging calls
* Add Red Hat 8 to RHEL 7 as a test
* Use past date to report RHEL 7 end of life
* Remove Red Hat 8 from RHEL 7 end of life
* Log more information
* Display end of support date
Incorrect to declare end of support as the date when we begin warning
the user about end of life.
* Add descriptions of the admin monitors
* Use a better redirect URL
* Group admin monitors better by display name
* Remove unnused message.properties files
* Add description.jelly file
* Better description of the admin monitors
* Add endOfSupportDate getter
Needed for UI
* Fix minor indentation error
* Each monitor must be independently disabled
* Repurpose identifier for use in disabled property
Don't need the idenitfier anywhere except in the initial constructor
call that is later used to enable and disable the admin monitor.
* Add Red Hat 8 to RHEL 7 as a test
* Add os-release tests and data files
* Remove unused URL arg to constructor
* Reduce duplication in data
Easier to test with symbolic constants that are consistently named across
all the classes.
Includes tests of os-release files from each of the end of life operating systems
* Fix inaccurate comment
* Use constant for documentation URL
* Remove RHEL 8 from RHEL 8 Admin Monitor
* Fedora 36 security support ends 18 May 2023
* Fedora 37 support ends 15 Dec 2023
* Fix spelling error in description
* Read data file with UTF-8 character set
* Do not use extension point name in symbol
* Use single word 'Ignore' in button, not name of monitor
* Use a smaller layout for monitor name
* Include operating system version in RHEL 7 check
Includes a TODO comment to remove the RHEL 8 entry that I use for
testing and development
* Fix regex syntax error
* First prototype using a data file
* Start the conversion to a single monitor
* Latest experiments with end of life data as JSON
* More exploring and evolving
* Remove Alpine admin monitor
* Remove Fedora admin monitor
* Remove Debian admin monitor
* Remove Ubuntu admin monitor
* Throw IOException rather than check for null
IOException should be uncommon and mistakes should be detected by
automated tests
* Stop inheriting from EndOfLifeAdminMonitor
* Simplify initialization logic
Else clauses not required due to break.
* Add isActivated implementation
* Add setDisabled test method
* Minor formatting changes
* Test some additional methods
* Call super in constructor
* Minor updates from study of upstream class
* Format JSON data
* Fix formatting errors
* Fix assertion
* Better variable naming
* Explain the purpose of ignoreEndOfLife flag
* Remove unused import
* Store the pretty name, not the pattern
* Test pretty name with sample os-release data files
* Remove RedHat 7 specific monitor
* Set RHEL 8 end of life early for test
* Ongoing debugging
* Describe the monitor
* Honor start date
* Add pretty name as monitor attribute
* Add end of support date
* Remove earlier implementations
* Move end of life data
* Rename end of support to end of life
End of life is used throughout the monitor
* Improve message with after end of life date status
* Undo .gitignore change
* Rename effective date to end of life date
* Rename pretty name to operating system name
* More rename of prettyName
* Fix logging mistakes
* Add RHEL 8
* Default start date is 6 months before end of life
* Add operating system end of life patterns and dates
* Fix JSON file formatting
* Simplify logging code
* Better logging
* Add Alma and Rocky Linux tests and patterns
* Add methods to help test automation
* Remove unused methods
* Start warning RHEL 7 users immediately
* Suppress spotbugs traversal_in warning - false positive
* Throw IOException on bad data file
Fail tests quickly when a a bad data file is used
* Better exception message
* Correct RHEL 8 end of life date
* Enable isActivated test
* Increase test coverage
* Fix spelling error
Co-authored-by: Alexander Brandes <brandes.alexander@web.de>
* Remove non-breaking spaces from message
Non-breaking spaces are not recommended.
Co-authored-by: Tim Jacomb <21194782+timja@users.noreply.github.com>
* Rename class to match symbol
https://github.com/jenkinsci/jenkins/pull/7913/files#r1199814150
* Sort end of life data alphabetically
* Included OS query parameter and fragment in docs URL
The fragment may be useful in the future for analytics. Harmless to
send the fragment to www.jenkins.io and www.jenkins.io may be able to
make use of it to direct the reader to information that is specific to
their operating system.
* Scientific Linux 8 does not exist
* Remove fragment, only need query parameter
https://github.com/jenkinsci/jenkins/pull/7913#discussion_r1200991347
is the comment that prompted the improvement.
---------
Co-authored-by: Alexander Brandes <brandes.alexander@web.de>
Co-authored-by: Tim Jacomb <21194782+timja@users.noreply.github.com>
Co-authored-by: Alexander Brandes <mc.cache@web.de>
https://issues.jenkins.io/browse/JENKINS-70895 reports that
`isSecureContext` is not recognized by HTMLUnit in its JavaScript
handling. That breaks tests for some plugins that use HTMLUnit to test
configuration round trips.
https://github.com/jenkinsci/jenkins/pull/7665 introduced this change
to notify users running over HTTP connections (insecure) that the copy
button does not work over insecure connections.
https://issues.jenkins.io/browse/JENKINS-21052 was the original motivation
for that informational message to the user.
James Nord tested this change in the automated test that was failing
with Jenkins 2.397 and confirmed that the test passes with this change.
I tested interactively over HTTP and confirmed that the copy button on
the inbound agent page still reports that copy is not supported over an
insecure session.
I tested interactively over HTTPS and confirmed that the copy button on
the inbound agent page still correctly copies the expected content.
I spent several unsuccessful hours trying to create an automated test
to show the failure. I think we should include this fix without an
automated test because the automated tests in the plugin that James
maintains will detect the issue.
Warn user that the copy button requires HTTPS
Users that run Jenkins over an unencrypted (HTTP) connection will see
the copy button, but it does not perform a copy. Browsers will only
allow access to the clipboard if the page is in a secure context.
With this change, the text that is displayed when the user clicks the
copy button from an insecure context will alert the user that copy
requires a secure connection.
https://stackoverflow.com/questions/400212/how-do-i-copy-to-the-clipboard-in-javascript
describes the alternatives in more detail.
https://issues.jenkins.io/browse/JENKINS-21052 reported that the copy
button does not work. I've confirmed that it works when using an HTTPS
connection.
* Test redirect from installNecessaryPlugins
Jenkins LTS versions prior to 2.375.1 redirected to an existing URL.
Jenkins 2.375.1 - 2.375.3 redirect to a non-existent URL.
Test that the old behavior is restored.
* [JENKINS-70599] restore installNecessaryPlugins redirect destination
The installNecessaryPlugins API end point previously redirected to the
"/updateCenter" URL. When the side bar was added to the plugin
manager, the redirect was changed to "/updates". Unfortunately, there
is no page at "/updates", while there is a page at "/updateCenter".
This restores the redirect for the installNecessaryPlugins API call.
If the redirect is not restored, calls to the API that follow the redirect
fail with a page not found (HTTP 404).
I did not find any callers to that API from inside Jenkins core.
Change introduced in 6db88c3f5b
* Use default HttpClient version
The HttpClient documentation notes that if the default is selected but
not supported, then the client will automatically downgrade to HTTP 1.1.
Browsers only support HTTP 2 over TLS, but that's not a requirement of
the HTTP 2 specification.
https://http2.github.io/faq/#does-http2-require-encryption
* Adjust test timeouts based on actual test results
Tests on ci.jenkins.io showed that installNecessaryPluginsTest completes
as follows:
* 9.4 seconds Windows JDK 17
* 0.8 seconds Linux JDK 11
* 1.0 seconds Linux JDK 17
* 1.1 seconds Linux JDK 19
With those timings, it seems reasonable to set the crumb request to
timeout in not more than 7 seconds and the plugin installation request
to timeout in not more than 20 seconds. That will waste a little less
time in execution if there is a problem and still leaves room for low
performance systems.
* Redirect to newer pluginManager URL
* Hide split of windows-slaves from other plugins
https://issues.jenkins.io/browse/JENKINS-70301 notes that the WMI Windows
Agents plugin (id:windows-slaves) was split from core in 1.547 and is
now deprecated. Because it is deprecated, users want to remove it.
They cannot remove it if they have plugins installed that depend on a
Jenkins version prior to 1.547.
Only two plugins actually depend of any classes from the WMI Windows
Agent plugin.
* cli-extras-plugin - never released, no tags, no install history
* multi-slave-config - already requires windows-slaves plugin explicitly
and already requires a Jenkins core version newer than 1.547. 1340
installations, last released 8 years ago
Rather than require updates of all the plugins that require a Jenkins
version less than 1.547, this removes the windows-slaves plugin from the
split plugins list. Users will not be warned that their plugin might
have a dependency on windows-slaves because the analysis has confirmed
that there is only 1 delivered plugin with that dependency, and it is
an explicitly declared dependency with a newer Jenkins minimum version
than the version from which the WMI Windows Agents plugion was split.
Testing done
* Installed suggested plugins from wizard and confirmed WMI Windows
Agents plugin is not installed
* Installed slave-setup plugin (has implied WMI Windows Agents plugin
dependency) and confirmed that WMI Windows Agents plugin is not installed
* Installed multi-slave-setup plugin (has explicit WMI Windows Agents
plugin dependency) and confirmed that WMI Windows Agents plugin was
installed as a dependency
* Remove multi-slave-setup plugin and WMI Windows Agents plugin and
confirmed that Jenkins reported no errors or issues
* Installed five plugins with old base versions and confirmed
that WMI Windows Agents plugin was not installed. The five plugins
included backup-plugin, cloudbees-credentials-plugin, unity3d-plugin,
groovy-label-assignment-plugin, and maven-deployment-linker plugin.
* Performed a backup with the backup plugin and confirmed that it was
well behaved
https://docs.google.com/spreadsheets/d/1KDIJIu41rIRlj6PjzyhAY9vazKmd3PVwqM3_-32Lt-o/edit?usp=sharing
lists the plugins that have an implied dependency on the WMI Windows
Agents plugin.
* Remove windows-slaves from war file
No need to bundle a detached plugin that has no consumers of its API
that are based on a Jenkins version before the plugin was split from core.
https://github.com/jenkinsci/jenkins/pull/7568#pullrequestreview-1238137930
detected that the bundling was left in by the original commit.
Retain internal consistency in the code.
Since value is set to null if it is an empty string,
it makes sense to set valueHex to null if value
is null.
Co-authored-by: Basil Crow <me@basilcrow.com>
https://community.jenkins.io/t/reverse-proxy-test-does-not-handle-url-correctly/1294/9
reports that an empty value returned to the URI encoding check monitor
will report a null pointer exception. An empty value is unexpected in
that context, but it is easy to check for null and avoid the null
pointer exception.
No Jira ticket was opened for the issue. I can open a Jira ticket if
that is required.
Mark Waite