feat(java): Require Jenkins core 2.479.3 and Java 17

[gounthar]

Hello tekton-client developers! 👋

This is an automated pull request created by the Jenkins Plugin Modernizer tool. The tool has applied the following recipes to modernize the plugin:

Upgrade to the next major parent version (5.X) requiring Jenkins 2.479 and Java 17

io.jenkins.tools.pluginmodernizer.UpgradeNextMajorParentVersion

Upgrade to the next major parent version (5.X) requiring Jenkins 2.479 and Java 17.

Why Upgrade to Java 17 and Jenkins 2.479.x?

• Embrace Java 17 LTS Stability: Benefit from long-term support with modern language features that improve development practice and plugin performance.

• Harness Jenkins 2.479.x Innovations: Stay aligned with the latest features and stability improvements, ensuring smooth integration and future-proofing.

• Enhance Security: Protect your plugin with up-to-date security fixes from both Java 17 and Jenkins core improvements.

• Align with the Community: Keep pace with ecosystem shifts towards Java 17, ensuring compatibility and expanding your plugin's user base.

• Enjoy a Better Developer Experience: Make the most of advanced tooling support and simplified dependency management with Java 17's enhancements.

Removing developers Tag from pom.xml

Jenkins no longer requires the developers tag in pom.xml, as the developers section was traditionally used to list individuals responsible for the plugin.
Instead, Jenkins now uses the Repository Permission Updater (RPU) to manage permissions and developer information.

Benefits of Removing developers Tag:

• Simplification: Removes unnecessary metadata from the pom.xml, resulting in a cleaner and more maintainable file.
• Consistency: Centralizes developer information management through the RPU, minimizing discrepancies.
• Security: Utilizes the RPU's controlled permission management, enhancing the security of artifact deployments.

Removing the developers tag aligns with modern Jenkins infrastructure standards and prevents outdated or redundant developer information from being included in plugin metadata.

JEP-227: Replace Acegi Security with Spring Security

Migrating Jenkins plugin code from Acegi Security to Spring Security is important for several reasons:

• Security updates: Spring Security is the modern, actively maintained successor to Acegi Security, providing up-to-date security features and patches.
• Compatibility: Jenkins core version 2.266 and later have replaced Acegi Security with Spring Security, so plugins need to be updated to remain compatible with newer Jenkins versions.
• Eliminating false positives: Security scanners often flag the outdated Acegi Security library as vulnerable, causing unnecessary concerns and exemption requests in security-conscious organizations.
• Reducing technical debt: The Acegi Security code in Jenkins was written over 13 years ago and has barely been touched since, making it difficult to maintain and understand.
• Access to modern features: Spring Security offers more current security implementations and features that weren't available in Acegi Security.
• Community support: With the Jenkins ecosystem moving to Spring Security, plugins using the newer library will benefit from better community support and compatibility with other plugins.
• Simplified API: The migration offers an opportunity to introduce a new simplified security API in Jenkins, potentially making it easier for plugin developers to work with security-related functions.

By migrating to Spring Security, plugin developers ensure their code remains compatible with current Jenkins versions, benefit from modern security features, and contribute to a more secure and maintainable Jenkins ecosystem.

Summary

By upgrading, you'll be positioning your plugin at the forefront of performance, security, and user satisfaction. We encourage you to explore these updates and provide feedback. Let's continue to build a robust Jenkins ecosystem together!

[krisstern]

Hi @gounthar it looks like you may want to merge the latest changes from master into this branch before we can review it as some CI/CD checks are currently failing.

[gounthar]

Thanks, Kris.

After an update and a few fixes, this PR's code compiled on my machine; and I managed to build the HPI.

The reason the checks aren't succeeding here is most likely because the infrastructure is still building this code with JDK 8, using the Jenkinsfile content from the default branch.

Could you please replay the Jenkins check by replaying the build with the supplied Jenkinsfile content?

Thanks.

[krisstern]

Yes, it looks like this file needs to be updated as well:

tekton-client-plugin/.github/workflows/cd.yaml

Line 21 in 9ea20d0

java-version: 8

[krisstern]

Maybe even more files in https://github.com/jenkinsci/tekton-client-plugin/tree/9ea20d07a8107d173fc06ebed3be11d9c4ccc186/.github/workflows need to be updated

[gounthar]

@krisstern : only 2 checks are failing now, due to the use of JDK8 in the infra.
If you have the right permissions, could you please try to replay this Jenkins build with the supplied Jenkinsfile content?
Thanks.

[krisstern]

I tried replaying the two failing tests but to no avail. It seems like the Linux Java JDK version is stuck at 8. Maybe I could try "merging without waiting for requirements to be met (bypass rules)", but that feels a bit risky.

[krisstern]

@gounthar could you please try this before we give up?: Could you please squash your commits into one? I see you do not have the changes in the Jenkinsfile in your first commit. But this may or may not work. Do give it a try first.

[gounthar]

Yep, let's wait until someone knows how to deal with that.
Thanks, Kris. 👍

[krisstern]

Yep, let's wait until someone knows how to deal with that. Thanks, Kris. 👍

I think the changes to the linux build was not in the first commit, so that the changes did not get pick up. Could you please squash all your 8 commits into one and push again?

[krisstern]

Let me first run the tests locally, if all tests pass, I will merge the PR.

[krisstern]

I am seeing the following in the stack trace:

[WARNING] No SupportedSourceVersion annotation found on io.sundr.builder.internal.processor.BuildableProcessor, returning RELEASE_6.
[WARNING] Supported source version 'RELEASE_6' from annotation processor 'io.sundr.builder.internal.processor.BuildableProcessor' less than -source '17'
[WARNING] No SupportedSourceVersion annotation found on io.sundr.builder.internal.processor.ExternalBuildableProcessor, returning RELEASE_6.
[WARNING] Supported source version 'RELEASE_6' from annotation processor 'io.sundr.builder.internal.processor.ExternalBuildableProcessor' less than -source '17'
[WARNING] No SupportedSourceVersion annotation found on io.sundr.resourcecify.internal.processor.ResourcecifyProcessor, returning RELEASE_6.
[WARNING] Supported source version 'RELEASE_6' from annotation processor 'io.sundr.resourcecify.internal.processor.ResourcecifyProcessor' less than -source '17'

Are these safe to ignore @gounthar?

[gounthar]

I have no idea. :'(