使用通过pre-build shell命令获得的变量来设置Hudson中的Maven构建的选项 [英] Using a variable obtained using a pre-build shell command to set an option for the Maven build in Hudson

查看:176
本文介绍了使用通过pre-build shell命令获得的变量来设置Hudson中的Maven构建的选项的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有哈德森(Hudson)工作,可以实现目标.在执行该Maven目标之前,我已经添加了一个在构建开始之前要运行的步骤,它是一个Shell脚本,可在目标和选项"字段中获取要使用的版本号.

因此,在我的工作配置中,在 Build Environment 下,我选中了 Configure M2 Extra Build Steps 框,并在构建之前添加了一个Shell脚本.该脚本如下所示:

export RELEASE={command to extract release version}
echo $RELEASE

然后在 Build 部分下,指向"root pom".然后,在目标和选项中,我希望能够执行以下操作:

-Dbuild.release.version=${RELEASE} deploy

其中 build.release.version 是POM中引用的maven属性.但是,由于shell似乎并未使其变量成为全局变量,因此它不起作用.有什么想法吗?

我唯一需要安装的是 Envfile 插件并获取shell脚本以将RELEASE属性写到文件中,然后让插件读取该文件,但是一切运行的顺序可能会导致问题,并且似乎必须有更简单的方法...是吗?

谢谢.

解决方案

我最近想做同样的事情,但是AFAIK不可能将值从预构建外壳导出到作业环境.如果有针对此的Hudson插件,我会错过的.

但是,起作用的是与您建议的设置类似的设置:让预构建Shell脚本将所需的值写入工作空间中的属性文件,然后使用参数化触发插件触发另一项实际完成工作的工作(在您的情况下,调用Maven作业).可以将插件配置为从属性文件读取其传递的参数.因此, first 作业仅具有shell脚本和生成后触发器,而 second 则完成实际工作,并具有可作为环境变量使用的正确参数.

shell脚本的一般概念:

echo "foo=bar
baz=`somecmd`" > build.properties

对于您的目标和选项,类似:

-Dbuild.release.version=${foo} deploy

当然,这并不理想,但是对我们来说确实很好,因为我们的构建最初被分解为几个工作,并且我们实际上可以重用第一个触发的其他工作(即,请使用不同的参数调用它们.)

I have a Hudson job that runs a maven goal. Before this maven goal is executed I have added a step to run before the build starts, it is a shell script that obtains the version number that I want to use in the 'Goals and options' field.

So in my job configuration, under Build Environment I have checked the Configure M2 Extra Build Steps box and added a shell script before the build. The script looks like this:

export RELEASE={command to extract release version}
echo $RELEASE

And then under the Build section I point to my 'root pom'. In the Goals and options I then want to be able to do something like this:

-Dbuild.release.version=${RELEASE} deploy

Where build.release.version is a maven property referenced in the POM. However since the shell doesn't seem to make its variables global it doesn't work. Any ideas?

The only one I have is to install the Envfile plugin and get the shell script to write out the RELEASE property to a file and then get the plugin to read the file, but the order in which everything is run may cause problems and it seems like there must be simpler way...is there?

Thanks in advance.

解决方案

I recently wanted to do the same, but AFAIK it's not possible to export values from a pre-build shell to the job environment. If there is a Hudson Plugin for this I've missed it.

What did work, however, was a setup similar to what you were suggesting: having the pre-build shell script write the desired value(s) to a property-file in the workspace, and then using the Parametrized Trigger Plugin to trigger another job that actually does the work (in your case, invoke the Maven job). The plugin can be configured to read the parameters it passes from the property file. So the first job has just the shell script and the post-build triggers, and the second one does the actual work, having the correct parameters available as environment variables.

General idea of the shell script:

echo "foo=bar
baz=`somecmd`" > build.properties

And for your Goals and options, something like:

-Dbuild.release.version=${foo} deploy

Granted, this isn't as elegant as one might want but worked really well for us, since our build was broken into several jobs to begin with, and we can actually reuse the other jobs that the first one triggers (that is, invoke them with different parameters).

这篇关于使用通过pre-build shell命令获得的变量来设置Hudson中的Maven构建的选项的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆