如何配置单个 Jenkins 作业以从主干或分支进行发布过程? [英] How to configure a single Jenkins job to make the release process from trunk or branches?

问题描述

我目前正在 Jenkins (1.430) 上改进我们项目的发布流程.

当前发布的工作

今天，对于一个特定项目，我们有一项专门用于发布流程的工作.完整流程如下:

1. 负责发布的开发者手动更改所有 pom.xml 文件的版本(实际上是使用 mvn versions:set -DnewVersion=2.0)去掉-快照.
2. 然后，他在 SVN (http://my-svn-repo/project/tags/V_2_0 例如).
3. 创建此标签后，他会登录我们的 Jenkins 服务器，并开始发布版本.
4. 这个构建会询问他想在构建中使用哪个标签.作业配置为参数化构建，带有参数列出 Subversion 标签.
5. Jenkins 将从此标签构建工件，并将它们部署到我们的 Nexus 实例上.
6. 完成此操作后，开发人员将 pom.xml 版本设置为新的开发版本(即 2.1-SNAPSHOT).

这种方法的优点是我只有 Jenkins 工作，因为构建将只依赖于一个标签.

然而，这个过程涉及太多的人为干预(更改 pom.xml、提交、标签等).

新发布的工作

现在，我使用 Maven 发布插件.我创建了一个作业，向启动构建的用户询问三个信息:

• 发布版本(发布插件的参数releaseVersion)；
• 开发版本，发布后(发布插件的参数developmentVersion)；
• 标签名称(发布插件的参数tag).

这项工作工作正常，除了一点:该工作基于 SVN 中的主干或分支.这意味着如果我有 2 个分支(除了主干)，我将需要创建 3 个发布作业:每个分支一个.

保留两个世界中最好的一个想法(即使用 mvn release，但保留 1 个发布作业)它添加一个构建参数，该参数将询问用户主干/分支的路径.因此，而不是在作业配置，我会设置http://my-svn-repo/project/$FROM_BRANCH，并要求用户输入FROM_BRANCH参数.

此解决方案的问题是用户必须输入trunk 或branches/BRANCH_Vx，这可能会导致错误.

理想情况下，我希望有一个构建参数，让我可以选择分支(包括主干)，因为参数 List Subversion tags 存在用于选择标签...

所以我的问题是:有没有更好的方法来配置可以在所有分支上运行的一个 Jenkins 作业?

谢谢.

---

编辑:我找到了 验证字符串 Jenkins 插件，它可以确保用户定义的值遵守一些正则表达式.这对我来说很有帮助...

解决方案

您需要 Subversion 插件的 1.32 版.issue JENKINS-10678 已在该版本中实现.

然后你只需给它你的项目 URL(需要包含主干、分支和标签)，它就会为你提供主干和你的分支.

I am currently enhancing the release process of our projects on Jenkins (1.430).

Current release jobs

Today, for one specific project, we have one job dedicated to the Release process. The complete procedure is the following:

1. The developer who is in charge of the release changes manually the version of all the pom.xml files (in fact using mvn versions:set -DnewVersion=2.0) to get rid of the -SNAPSHOT.
2. Then, he creates a tag in SVN (http://my-svn-repo/project/tags/V_2_0 for example).
3. Once this tag has been created, he logs on our Jenkins server, and starts a Release build.
4. This build will ask him which tag he wants to use for the build. The job is configured as a Parameterized build, with the parameter List Subversion tags.
5. Jenkins will then build the artifacts from this tag, and deploy them on our Nexus instance.
6. Once this is done, the developer set the pom.xml versions to the new development version (i.e. 2.1-SNAPSHOT).

The advantage of this method is that I have only Jenkins job, as the build will rely only on a tag.

However, this procedure involves too many human interventiosns (changes of the pom.xml, commits, tags, etc.).

New release jobs

Now, I use the Maven release plugin. I've created a job that asks three information to the user who launches the build:

• the version of the release (parameter releaseVersion of the release plugin);
• the version of development, after the release (parameter developmentVersion of the release plugin);
• the name of the tag (parameter tag of the release plugin).

This job works fine, except for one point: the job is based on the trunk or on a branch in SVN. This means that if I have 2 branches (in addition to the trunk), I will need to create 3 release jobs: one per branch.

One idea to keep the best of the two worlds (i.e. using mvn release, but keeping 1 release job) it to add a build parameter that will ask the user for the path of the trunk / branch. So instead of setting http://my-svn-repo/project/trunk (or http://my-svn-repo/project/branches/BRANCH_V1) in the job configuration, I will set http://my-svn-repo/project/$FROM_BRANCH, and ask the user to input the FROM_BRANCH parameter.

The problem with this solution is that the user will have to input either trunk or branches/BRANCH_Vx, which may lead to errors.

Ideally, I would love to have a build parameter that let me the choice of the branch (including trunk), as the parameter List Subversion tags exist for the choice of tags...

So my question: is there a better way to configure one Jenkins job that can work on all the branches?

Thanks.

---

Edit: I found the Validating String Jenkins plugin that can be interesting to ensure that the value defined by the user respects some regular expression. That is helpful in my case...

解决方案

You need version 1.32 of the subversion plugin. The issue JENKINS-10678 was implemented in that version.

Then you only give it your project URL (which needs to contain trunk, branches, and tags) and it will offer you the trunk together with your branches.

这篇关于如何配置单个 Jenkins 作业以从主干或分支进行发布过程?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！