返回博客

隆重推出用于 Jenkins 插件开发的 Gradle Convention Plugin

Aarav Mahajan 2025 年 8 月 31 日

使用 Gradle 构建 Jenkins 插件变得更加容易！
隆重推出现代化、Kotlin 优先、基于约定的 Jenkins Gradle Convention Plugin。插件开发变得毫不费力 🏄‍♂️🏎️。
🌀 立即在 Gradle Plugin Portal 上试用

当今 Jenkins 插件的开发格局

Apache Maven 仍然是 Jenkins 插件开发的主要且官方推荐的构建工具，为绝大多数生态系统中的插件提供支持。它与 Jenkins 插件父 POM 的强大集成、丰富的文档和成熟的生命周期支持，使其成为大多数开发者的最安全和默认的选择。

Gradle 虽然在技术上功能强大且在更广泛的 Java 生态系统中被广泛采用，但在 Jenkins 社区中的采用率有限。它提供了强大的优势，包括

  • 可扩展的构建逻辑，以代码而非僵化的 XML 定义。

  • 通过增量构建、缓存和 Gradle Daemon 实现更快的构建速度。

  • 通过 Kotlin 和 Groovy DSL 以及交互式工具提供开发者友好的体验。

  • 约定插件 — 一种跨项目共享和重用标准化构建逻辑的强大方法。它们可以像特质一样组合，类似于 OOP 中的多重继承或菱形继承。相比之下，Maven 的父 POM 模型仅允许一个父级（自 Maven 3 以来），迫使开发者依赖于繁重的配置文件使用和样板代码。

尽管有这些优势，Jenkins 插件开发仍然由 Maven 主导。主要原因是核心构建基础设施、工具生态系统和 CI 管道与 Maven 的约定深度对齐。

下表重点介绍了 Maven 和 Gradle 在 Jenkins 插件开发中的一些关键差异。

Comparison table showing differences between Maven and Gradle for Jenkins plugin development

动机

2022 年末，Jenkins 社区发现了 Gradle 在插件托管和自动化方面存在显著的不足。当时，使用 Gradle 的新开源 Jenkins 插件甚至因这些要求未得到满足而被阻止托管。

这引发了旨在弥合差距的讨论和社区倡议。Jenkins Gradle Convention Plugin 是该努力的直接成果，它提供了一种标准化且受支持的方式，使用 Gradle 来构建 Jenkins 插件。

Gradle JPI 插件的不足之处？

面向 Jenkins 插件开发的 Gradle JPI 插件提供了一条不依赖 Maven 的路径，但在匹配完整的基于 Maven 的体验方面存在不足。主要限制包括

  • **不符合 Jenkins 托管要求** → 阻碍接受

  • **不支持 Plugin Compatibility Tester (PCT)** → 跨版本测试薄弱

  • **依赖管理 & BOM 差距** → 构建不可靠

  • **过时的基于 Groovy 的代码库** → 维护难度大

  • **没有约定插件** → 开发人员面临更多的配置开销

认识 Jenkins Gradle Convention Plugin

一个 Kotlin 优先的 Gradle 约定插件，它充当了使用 Gradle 进行 Jenkins 插件开发的 Maven 父 POM 的等效物。它建立在成熟的 gradle-jpi-plugin 之上，为构建、测试和发布 Jenkins 插件提供了一个统一、有主见的平台，标准化最佳实践，自动化质量检查，并消除了样板代码。

Rahul 和 Steve 推出了 Gradle JPI 插件的“JPI2”新变体，增加了对 Gradle 8+ 的支持、改进的依赖处理和现代化的架构。约定插件设计为向前兼容，一旦 JPI2 API 稳定，我们计划将约定插件迁移到利用它，以获得更好的体验。

由我本人在 **Google Summer of Code (GSoC) 2025** 项目中，与 **Gradle**、**Netflix** 和 **Kotlin Foundation** 合作开发，并在 Oleg Nenashev、Steve Hill 和 Rahul Somasunderam 的专家指导下完成。他们的指导非常有价值，该插件将持续积极维护。

它带来了什么？

  • **现代化语言标准强制执行**：最大限度提高 Java、Kotlin 和 Groovy 的生产力，配置最少/零配置

  • **Jenkins 托管合规性**：已处理 PCT 支持、元数据和结构

  • **智能依赖管理**：自动 BOM 对齐和零版本冲突 -
    告别 依赖地狱

  • **质量门禁 & 报告**：预配置的工具，提供统一的、CI 准备就绪的报告

  • **现代化测试生态系统**：现成的测试堆栈，经过优化执行，可实现可靠、快速的 Jenkins 插件测试

  • **配置 & 可扩展性**：适用于多模块项目的灵活 DSL 或基于属性的设置

  • **面向未来**：拥抱 Gradle 9 的最佳实践，如配置缓存、版本目录和缓存

几秒钟内即可上手

  • 步骤 1：在项目的 libs.versions.toml 文件中定义插件

[versions]
jenkinsConvention = "<LATEST_VERSION>"

[plugins]
jenkinsConvention = { id = "io.github.aaravmahajanofficial.jenkins-gradle-convention-plugin", version.ref = "jenkinsConvention" }

  • 步骤 2：配置版本目录

在根目录的 settings.gradle.kts 中，添加插件的版本目录

dependencyResolutionManagement {
    repositories {
        mavenCentral()
    }
    versionCatalogs {
        create("baseLibs") {
            from("io.github.aaravmahajanofficial:version-catalog:<LATEST_VERSION>")
        }
    }
}

  • 步骤 3：基本构建脚本

在根目录的 build.gradle.kts 中，添加以下内容

plugins {
    alias(libs.plugins.jenkinsConvention)
}

jenkinsConvention {
    // Only override the defaults that need to be customized for your plugin.

    // Set the Jenkins version (default: as per version catalog).
    jenkinsVersion = "2.525"
}

就是这样！ 享受预配置的工具、同步的 BOM、PCT 支持和现成的合规性检查。

路线图

插件交付和集成的下一步

  • 支持 Jenkins 插件的持续交付

  • 与 Jenkins 管道无缝集成（例如，CI 的 buildPluginWithGradle）

  • 在新 API 稳定后迁移到 Gradle JPI2 插件

我邀请所有 Jenkins 社区的开发人员——特别是基于 Gradle 的插件的维护者——试用它，提供反馈，并帮助将其精炼成一个有利于所有人的稳定工具链。非常欢迎贡献、实际测试和讨论 。

了解更多

以大象 🐘 结尾

这个插件不仅仅是另一个构建工具的小改动——它是关于让 Gradle 成为 Jenkins 插件开发中的一个*一等公民*。让我们将现代生产力工程引入 Jenkins 生态系统。

感谢阅读！ **如果您觉得有用，请给仓库加星或贡献。**

关于作者

Aarav Mahajan

Aarav 是印度旁遮普邦 Thapar 工程与技术学院的一名专注的计算机工程专业的学生，对 DevOps 和云技术充满热情。他热衷于学习新技术并将其应用于解决现实世界的问题，对可扩展和安全的云基础设施有着浓厚的兴趣。他目前是 Kotlin Foundation 的 Google Summer of Code (GSoC) 2025 贡献者，在那里他正在开发一个旨在简化 Jenkins 插件开发者工作流程的新 Gradle 约定插件，以增强构建自动化和集成。

© . This site is unofficial and not affiliated with The Linux Foundation.