Bump jenkins.version from 2.371 to 2.377 for bom-weekly

[github-actions]

Bump jenkins.version from 2.371 to 2.377 for bom-weekly

Report

Source:
	✔ [jenkins] Get Last jenkins Weekly Version(jenkins)


Condition:
	✔ [jenkins] Test if Jenkins stable published(maven)

Target:
	✔ [jenkins] Update Jenkins version(shell)

Changelog

Click to expand

Jenkins changelog is available at: https://www.jenkins.io/changelog/#v2.377

Remark

This pull request was automatically created using Updatecli.

Please report any issues with this tool here

[jglick]

Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.10.1:compile (default-compile) on project gitlab-plugin: Compilation failure: Compilation failure: 
/home/jenkins/agent/workspace/Tools_bom_PR-1479/pct-work/gitlab-plugin/src/main/java/com/dabsquared/gitlabjenkins/trigger/handler/push/OpenMergeRequestPushHookTriggerHandler.java:[62,78] error: incompatible types: Collection<Trigger<?>> cannot be converted to Collection<Trigger>
/home/jenkins/agent/workspace/Tools_bom_PR-1479/pct-work/gitlab-plugin/src/main/java/com/dabsquared/gitlabjenkins/GitLabPushTrigger.java:[555,68] error: incompatible types: Collection<Trigger<?>> cannot be converted to Collection<Trigger>

[jglick]

Probably related somehow to jenkinsci/jenkins#7131 though I am not quite sure how.

[MarkEWaite]

I can see the failure when I attempt to compile the gitlab plugin with JDK 17 and Jenkins 2.375. I'm currently one of the maintainers of the gitlab plugin. I'll try to prepare a new release of the gitlab plugin that fixes the compile issue and includes JDK 17 and Jenkins 2.375 in the tests run by the Jenkinsfile.

[jglick]

I am working on it already.

[jglick]

The real problem here is that a compilation error against a newer core even matters to begin with. PCT used to compile against the plugin’s declared baseline and only run tests against alternate versions. I think this got broken in #1336 (CC @basil); could probably be fixed by enhancing PCT to allow you to separately declare Maven properties to be used for the compile command vs. for the test command. As it stands, passing -Djenkins.version in both commands, there is no advantage to even separating these commands at all, so we get the downsides (test runs do not use the same bytecode as the current plugin release, which matters in some weird binary compatibility cases; and PCT runs are vulnerable to source incompatibility issues like this one) without the upside (simplified and faster operation that could work better for multimodule repositories). Related: jenkinsci/maven-hpi-plugin#336 (comment) jenkinsci/plugin-compat-tester#384 (comment)