使用通过预构建 shell 命令获得的变量为 Hudson 中的 Maven 构建设置选项

Question

我有一份 Hudson 工作，运行一个 Maven 目标。在执行此 Maven 目标之前，我添加了一个在构建开始之前运行的步骤，它是一个 shell 脚本，用于获取我想要在“目标和选项”字段中使用的版本号。

因此，在我的作业配置中，在构建环境下，我选中了配置 M2 额外构建步骤框，并在构建之前添加了 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属性写到文件中，然后让插件读取文件，但是所有内容的运行顺序可能会导致问题，似乎必须有更简单的方法......有吗？

提前致谢。

Answer 1

我最近想做同样的事情，但据我所知，不可能将值从预构建 shell 导出到工作环境。如果有一个 Hudson 插件，我已经错过了。

然而，真正有效的是与您建议的设置类似的设置：让预构建 shell 脚本将所需的值写入工作区中的属性文件，然后使用 参数化触发器插件 来触发另一个实际执行工作的作业（在您的情况下，调用 Maven工作）。该插件可以配置为读取它从属性文件传递的参数。因此，第一个作业只有 shell 脚本和构建后触发器，第二个作业则执行实际工作，并具有可用作环境变量的正确参数。

shell 脚本的总体思路：

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

对于您的目标和选项，类似于：

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

当然，这并不像人们想要的那么优雅，但对我们来说效果非常好，因为我们的构建一开始就被分成了几个工作，并且我们实际上可以重用第一个触发的其他作业（即使用不同的参数调用它们）。

Answer 2

当你说它不起作用时，你的意思是你的RELEASE变量没有传递给maven命令吗？我认为问题在于默认情况下，shell 脚本的每一行都是单独执行的，因此环境变量会丢失。

如果您希望整个 shell 脚本像一个脚本文件一样执行，请创建第一行：

#!/bin/sh

我认为这在 shell 脚本构建步骤旁边的帮助信息中进行了描述（如果我错了，那么这是一个好地方寻找正确的语法）。