Conversation
Fork count of 3 often fails on ci.jenkins.io with an out of memory error in maven. Use the default and accept slower performance on multi-core machines.
Since the test already had a JenkinsRule, use it to make passing and failing HTTP requests to the notifyCommit URL and to other URL's. Uses a single JenkinsRule for the entire class of tests, since none of them alter the state of Jenkins enough to justify restarting Jenkins. Saves the time of stopping and starting Jenkins for each test.
Intentionally made public to prevent Java 11 mocking failure due to class loading of a non-public interface in a different class loader than the mocking framework. Since this is a test, it seems quite safe to make the interface slightly more visible than private. The message from mockito is: The type is not public and its mock class is loaded by a different class loader. This can have multiple reasons: - You are mocking a class with additional interfaces of another class loader - Mockito is loaded by a different class loader than the mocked type (e.g. with OSGi) - The thread's context class loader is different than the mock's class loader Not clear to me why this is an issue only with the update of the minimum Jenkins version from 2.138.4 to 2.204.1, but the change is only in test code and only to assist a mocked test so that it continues to be well-behaved.
|
Merge of this PR will need to wait until I can diagnose and resolve the test failures. The test failures are on Windows in cleanup and build log file removal from GitStatusTest (my CI infrastrastructure) and BuildSingleRevisionOnlyTest (ci.jenkins.io) on Windows. Usually those types of test failures point to a real problem with something that is holding locks. Unfortunately, in all the cases, the file that cannot be removed is the build log file. I believe the plugin relies on Jenkins core to close the build log file after a job completes, but there may be missing calls to wait for job completion before exiting the tests that are failing. Fixed in 02fc093 by waiting for test to complete on Windows before ending the test. |
Windows job cleanup fails to delete build logs in some of these tests. Wait for the jobs to complete before exiting the test so that the build logs will not be active when the cleanup process tries to delete them. The build logs which are not being promptly released are logs that Jenkins core maintains. It seems like Jenkins core should be the one that is responsible to assure the locks are released before the test exits. However, that might slow tests by blocking their exit unnecessarily on platforms that allow open files to be deleted.
|
@MarkEWaite any plans to release this? |
|
@jglick yes, @fcojfernandez, @rsandell and I agreed that we'll target the next release of the git plugin at roughly the same time as the release of Jenkins 2.235.1 long term support. That will deliver the user interface fixes that are also included in the master branch. Benefits
Remaining WorkThere are several "must have" items yet to be completed before git plugin 4.3 can be released:
There are also some "nice to have" items that would make the 4.3 release even better:
|
ping |
|
I plan to release tomorrow with the current contents of the master branch. No new symbols, but JGit 5.8 in the git client plugin and minimum Jenkins version of 2.204.1. I'll review that plan with the git plugin performance improvement mentors tomorrow morning (@fcojfernandez , @justinharringa , and Omkar Deshpande) during our twice weekly meeting with @rishabhBudhouliya . The pull request to add symbols recently surprised me when it caused a compatibility failure during startup. I'd initially hoped to include the additional symbols in 4.3, but don't want to delay 4.3 for it. |
Require Jenkins 2.204.1
This pull request switches from requiring Jenkins 2.138.4 as minimum version to require Jenkins 2.204.1 as minimum version. Using a modern version like 2.204.1 includes the trilead-api separation from the Jenkins core and simplifies testing.
Checklist
Types of changes
Further comments
User based justification for choosing 2.204.1 as the new minimum version:
Users that are choosing to stay current with the git plugin are also choosing to stay current with Jenkins releases. That's a very good thing. Special thanks to the users for choosing to update to recent releases!
The Jenkinsfile is now configured to test Jenkins 2.204.6 on Windows with Java 8 and Jenkins 2.222.1 or 2.204.6 on Linux with both Java 8 and Java 11. It intentionally tests the most recent release of Jenkins 2.204.x while only requiring 2.204.1 so that users of 2.204.2 are not forced to update to use the git client plugin.
There are still some spotbugs warnings that will either need to be suppressed, resolved, or hidden by restoring the spotbugs settings that were used until the recent update to spotbugs 4.0.1. Specifically, the spotbugs threshold was previously set to 'High' with the effort set to 'Low'. The new settings invert that and set the threshold to 'Low' and the effort to 'Max'.
This change intentionally uses plugin pom 4.0-beta with the assumption that plugin pom 4.0 will be released within the next month or so. If it is not released in that time, then the most recent released parent will be used instead.
Matching pull request for git client plugin at jenkinsci/git-client-plugin#532