将发布版本参数传递给 Maven 中的下游作业

发布于 2024-12-09 02:49:17 字数 598 浏览 0 评论 0 原文

我是一名 Maven 菜鸟,目前正在使用 Maven/Jenkins 在发布任务后执行一些下游工作,但我的团队遇到了问题。

我们想要实现的目标是在执行主构建后将版本标记传递到下游作业中。我们一直在尝试使用 M2 插件来实现这一目标,但它似乎在构建->下游作业->发布周期中执行,并且我们需要有一个构建-> ;发布->下游作业模式。

因此,我们决定使用构建步骤创建一个单独的作业来执行发布 a 作为目标。以下是我们用来实现此目的的指令:

-Pdmt -Dresume=false release:clean release:prepare release:perform -DautoVersionSubmodules

放弃此作业的 M2 插件的结果是不再出现请求版本号的提示。随后,我们一直尝试通过构建后操作并传递预定义的参数来实现这一目标。我们这里的问题是知道如何根据先前执行的作业传入动态参数。

我们考虑的另一个角度是指定一个属性文件,主作业可以在下游作业使用它之前对其进行标记。

有谁对我们如何实现此工作流程有任何建议,或者是否可能?

I'm a Maven noob currently working with Maven/Jenkins to perform some downstream jobs on the back of a release task and my team has hit a problem.

What we are trying to achieve is to pass in the version tag into the downstream jobs once the main build has been executed. We had been trying to achieve this using the M2 plugin, but it appears to execute in a Build->Downstream Jobs->Release cycle, and we need to have a Build->Release->Downstream Jobs pattern.

We therefore decided to create a separate job using the build step to perform the release a as a Goal. Here's the directives we are using to achieve this:

-Pdmt -Dresume=false release:clean release:prepare release:perform -DautoVersionSubmodules

A consequence of abandoning the M2 plugin for this job has been that the prompt requesting the version number is no longer appearing. Subsequently, we've been trying to achieve this via the Post-build Actions, and passing in pre-defined parameters. The issue for us here is knowing how to pass in a dynamic parameter based on the previously executed job.

An alternative angle we were looking at was specifying a properties file that the main job could tokenize prior to it's usage in the downstream jobs.

Does anyone have any advice on how we might achieve this workflow, or if it's even possible?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

‖放下 2024-12-16 02:49:17

好的,JFTR 看起来像是 超出 maven 发布插件的范围

为了回答这个问题,我必须列举该版本所做的一些假设
插件。我可以告诉您这些基线假设,您可以决定是否> >像 Maven Release 插件这样的东西适合你。

这些假设是什么?

您的代码库将作为一个“单元”进行版本控制和发布。
这是什么意思?这意味着您将要发布一个
整个项目及其所有子模块。 [原文如此] 在 Github 中,这意味着 Maven
发布插件将在整个存储库上运行。

存储库、版本和由此产生的工件之间的复杂关系使我们无法以问题中描述的方式自动执行任务

OK, JFTR it looks like it's outside of the scope of the maven release plugin:

To answer the question I had to enumerate some of the assumptions made by the Release
plugin. I can tell you about these baseline assumptions and you can decide whether or not > something like the Maven Release plugin is appropriate for you.

What are these assumptions?

Your codebase is going to be versioned and released as a “unit”. What
does this mean? This means that you are going to be releasing an
entire project at once with all of its submodules. [sic] In Github it means that the Maven
Release plugin is going to operate on an entire repository.

The complex relationship of the repositories, releases and resultant artifacts prevent us from automating the task in the manner described in the question

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文