通过Jenkins工作部署maven的策略

时间:2013-04-22 13:45:28

标签: java maven jenkins

我有一个Jenkins工作,它使用maven构建目标'clean package deploy'作为主git分支。但是,由于nexus repo不允许重新部署,如果Jenkins作业第二次运行而没有更改版本,它将失败并出现预期的400 Bad Request错误:

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
    org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) 
    on project common-library: 
Failed to deploy artifacts: Could not transfer artifact 
    net.bacon.common:common-library:pom:1.2.13 from/to bacon-releases 
    (https://maven.bacon.com/nexus/content/repositories/releases): 
Failed to transfer file: 
    https://maven.bacon.com/nexus/content/repositories/releases/net/bacon/common/common-library/1.2.13/common-library-1.2.13.pom. 
Return code is: 400, ReasonPhrase:Bad Request.

任何人都可以提出不同的策略,即可以在不使Jenkins作业失败的情况下运行部署目标吗?

5 个答案:

答案 0 :(得分:4)

我们所做的是自动快照构建。然后,版本会自动递增。

对于发布版本,我们使用maven发布插件并手动输入版本。但是,您可以让发布插件完成工作。它将删除“-SNAPSHOT”构建,部署,然后,为下一个版本增加最后一个数字并再次附加“-SNAPSHOT”。

对于分发管理,您可以使用两个repos,一个用于快照,一个用于发布,具有不同的重新部署设置。

答案 1 :(得分:1)

我们采用“双重行动”解决方案:

  • 增量版
  • 运行 mvn install
  • 运行测试
  • 如果全部通过,我们会运行 mvn deploy

这样,在我们知道全部通过之前,我们不会尝试部署,每次都会部署一个独特的版本。

我希望这会有所帮助。

答案 2 :(得分:0)

您应该确保master上的每个提交都在pom文件中携带自己的版本号。所以你不会重新部署。

拒绝“重新部署”是有充分理由的:发布版本的内容永远不会改变。

如果您无法避免在master上提交相同版本号,请考虑将链接的jenkins作业更改为“clean install”(仅将工件存储在本地存储库中)并使用“clean deploy”创建新作业只能手动启动。

答案 3 :(得分:0)

这也是我们小组的问题。

我们希望maven尝试进行PASSIVE部署,因此如果部署存在于nexus,那么它将继续成功继续成功,如果部署在nexus中不存在,它将上传并部署成功。

我们希望jenkins在构建并通过覆盖检查后进行部署,但是如何进行部署以便只部署未部署的部署,并忽略已部署的部分。

我们的解决方案是自定义脚本。

答案 4 :(得分:0)

您可以使用候选版本概念。当您开始发布时,将-RC1添加到版本(例如1.1.0-RC1)。

下一次重新部署时,您将增加RC编号。当发布完成并且您想要生成新TAG时,您只删除该版本的RC。在TAG创建之前