Reduce Windows test time in CI

[MarkEWaite]

Reduce Windows test time in CI

The ci.jenkins.io configuration limits tests to 6 hours or less. Tests on Windows have failed with a timeout on Windows in 3 of 15 builds completed in the last 3 weeks. The last 7 builds that did not timeout on Windows took an average of 5 hours 46 minutes, with 4 of the 7 runs needing more than 5 hours 50 minutes.

When Windows tests fail due to the 6 hour timeout, they reduce confidence in tests of Jenkins core. Let's disable some tests on Windows to reduce the Windows testing time.

I selected the longest running test suites from the ci.jenkins.io report and the longest running tests in those long runnning test suites. I believe that all of the disabled tests are low value on Windows. They continue to be run on Linux and they will continue to run on developer desktops.

Disabling these 15 tests will save 3.5 minutes or more of Windows test time and should reduce the risk of a 6 hour timeout on Windows tests.

Testing done

• mvn -Dtest=ProjectTest,QueueTest,ViewTest,Security1809Test,Security3430Test verify
  passes

Compared test times on my 6 Windows agents before and after the change.

Before:

• 10 min
• 10 min
• 15 min
• 7 min 40 sec
• 9 min
• 10 min
• 6 min 41 sec
• 9 min 28 sec
• 8 min 4 sec
• 10 min
• 9 min 19 sec
• 6 min 37 sec
• 14 min

After:

• 7 min 5 sec
• 7 min 8 sec
• 5 min 45 sec
• 4 min 39 sec
• 6 min 49 sec
• 4 min 14 sec
• 6 min 31 sec
• 10 min
• 5 min 39 sec
• 6 min 20 sec
• 6 min 16 sec
• 4 min 12 sec
• 6 min 27 sec
• 5 min 14 sec
• 6 min 13 sec
• 4 min 12 sec
• 6 min 9 sec

Screenshots (UI changes only)

Before

After

Proposed changelog entries

• N/A

Proposed changelog category

/label skip-changelog

Proposed upgrade guidelines

N/A

Submitter checklist

• The issue, if it exists, is well-described.
• The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples). Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
• There is automated testing or an explanation as to why this change has no tests.
• New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
• New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
• UI changes do not introduce regressions when enforcing the current default rules of Content Security Policy Plugin. In particular, new or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
• For dependency updates, there are links to external changelogs and, if possible, full differentials.
• For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

N/A

Before the changes are marked as ready-for-merge:

Maintainer checklist

• There are at least two (2) approvals for the pull request and no outstanding requests for change.
• Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
• Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
• Proper changelog labels are set so that the changelog can be generated automatically.
• If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
• If it would make sense to backport the change to LTS, be a Bug or Improvement, and either the issue or pull request must be labeled as lts-candidate to be considered.

[Copilot]

Pull request overview

This PR reduces the likelihood of Windows CI jobs timing out (6h limit on ci.jenkins.io) by conditionally skipping a selected set of longer-running tests when executing on Windows in CI (detected via Functions.isWindows() and the CI environment variable), while keeping coverage on Linux and developer machines.

Changes:

• Add JUnit 5 assumeFalse(...) guards to skip specific tests on Windows CI.
• Introduce required imports (Assumptions.assumeFalse, hudson.Functions) in affected test classes.
• Apply the skip logic across targeted suites in hudson.model.* and jenkins.security.* tests.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
test/src/test/java/jenkins/security/Security3430Test.java	Skips three remoting-compatibility tests on Windows CI via assumeFalse(...).
test/src/test/java/jenkins/security/Security1809Test.java	Skips two SECURITY-1809 tests on Windows CI via assumeFalse(...).
test/src/test/java/hudson/model/ViewTest.java	Skips one SECURITY-2171 XSS regression test on Windows CI via assumeFalse(...).
test/src/test/java/hudson/model/QueueTest.java	Skips two queue-related tests on Windows CI via assumeFalse(...).
test/src/test/java/hudson/model/ProjectTest.java	Skips seven project-related tests on Windows CI via assumeFalse(...).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[timja]

What about something like this? junit-team/junit-framework#2487 (comment)

[MarkEWaite]

I'm willing to do that. I wasn't aware of the JUnit annotation technique. I chose the assumeFalse technique because it is used elsewhere in Jenkins core. It may be a few days before I can get to it, but I'm willing to make that change.

[MarkEWaite]

I'll try to make the transition for Jenkins core to switch from assumeTrue and assumeFalse to DisabledIf and related annotations. I think this pull request can be merged as it currently stands, then a separate pull request with the larger change to replace JUnit 4 assumptions with JUnit 5.1 DisabledIf annotations.

[MarkEWaite]

This PR is now ready for merge. We will merge it after approximately 24 hours if there is no negative feedback. Please see the merge process documentation for more information about the merge process.

/label ready-for-merge