Jenkis下游工作无法找到上游工件

Question

该设置用于构建和部署到Adobe AEM.

Master Build作业来自git存储库,构建和包,运行测试,然后触发应该使用上游作业构建的包的下游作业.

问题是下游作业失败并显示以下消息:

Unable to access upstream artifacts area /var/lib/jenkins/jobs/PROJECTNAME-Master-Branch/builds/2014-10-22_11-33-46/archive. Does source project archive artifacts?

在我看来,由下游作业触发的不知何故CopyArtifacts插件正在寻找错误位置的工件.正确的位置将是

/var/lib/jenkins/jobs/PROJECTNAME-Master-Branch/workspace/PROJECTNAME-*/**/*.jar,/var/lib/jenkins/jobs/PROJECTNAME-Master-Branch/workspace/PROJECTNAME-*/**/*.zip

但后来,它抱怨

java.io.IOException: Expecting Ant GLOB pattern, but saw '/var/lib/jenkins/jobs/PROJECTNAME-Master-Branch/workspace/PROJECTNAME-*/**/*.jar,/var/lib/jenkins/jobs/PROJECTNAME-Master-Branch/workspace/PROJECTNAME-*/**/*.zip'. See http://ant.apache.org/manual/Types/fileset.html for syntax

下游作业从另一个项目复制工件,然后构建是"触发此作业的上游构建"或"从最近完成的构建的工作区复制".没有人工作.

有任何想法吗？

Answer 1

TL; DR

您正在尝试使用工件而不首先存档它们.
您正在尝试使用绝对路径,但它们应该相对于$WORKSPACE和/或"归档位置".

完整答案

你误解了"神器"的概念,因为它与詹金斯有关.

什么是詹金斯文物

工件是在构建之后借助Archive the Artifacts构建后操作专门保留的文件.

当构建运行时,它运行在:
$WORKSPACE,在文件系统上通常驻留在
$JENKINS_HOME/jobs/$JOB_NAME/workspace
内部,你可以拥有你的SCM签出文件夹,临时构建文件,最终构建文件,二进制文件等.

的内容$WORKSPACE是挥发性的,你不应该依赖它,编译时间范围之外(和下游的工作是构建时间范围之外).$WORKSPACE不同主/从节点之间的内容可能不同,可以随时由管理员删除,也可以通过SCM更新/清理/结账删除.

了解整个约伯只有一个 也很重要.$WORKSPACE

但现在请注意您的构建历史记录,该列表中有几个条目,由构建号(#)和日期时间戳引用.这些都存储在:
$JENKINS_HOME/jobs/$JOB_NAME/builds/$BUILD_ID
与$BUILD_ID正在构建的日期,时间,像2014-10-22_11-33-46

将$WORKSPACE包含有关信息当前或最近的(和问题是:你永远无法知道这是否是"当前"或"最后")建设;
该builds文件夹包含所有过去(保留)构建执行的记录(这是构成左侧构建历史记录列表的内容),每个构建.

默认情况下,它仅包含Jenkins自身所需的内容:build.xml副本,更改日志信息,控制台日志.当您转到URL http://$JENKINS_URL/job/$JOB_NAME/[nn]/其中[nn]是数字作业构建/运行编号(#)时,它正在从builds文件系统上的文件夹中读取此信息.

要保留构建的工件(以避免它们被下一个构建覆盖,消除了恶劣空间,或者只是访问较旧的构建版本),您需要存档工件(使用相同标题的相同构建后操作).归档工件时,指示$WORKSPACE要保留的文件.当Jenkins进行归档时,它会将这些文件(保留路径[相对于$WORKSPACE]保留)放入:
$JENKINS_HOME/jobs/$JOB_NAME/builds/$BUILD_ID/archive/.
这样,您可以为以前的构建保留多组工件,而不仅仅是"最新/最后" $WORKSPACE.

为了完整起见,我将提到Jenkins的"永久链接",例如http://$JENKINS_URL/job/$JOB_NAME/lastSuccessfulBuild和/lastFailedBuild等,实际上是文件系统上的一个保留builds/$BUILD_ID文件夹的符号链接.

最后,通过"丢弃旧版本"对作业配置的选中标记,您可以控制保留多少构建运行以及保留多少工件(可以单独配置).默认情况下,所有都保留,但如果您开始保留工件,则需要考虑硬盘空间容量.

解决您的问题

因此,通过上面的信息,并查看您的错误消息,您现在应该看到Copy Artifacts插件正在/archive/构建部分下正确查找工件.

您还应该注意到Copy Artifacts插件在选择要复制的构建时不允许您选择"当前构建".它具有永久链接(如"最后成功"或"最后构建")和特定的构建号,所有这些都转换为保留的构建$JENKINS_HOME/jobs/$JOB_NAME/builds/$BUILD_ID/archive/

甚至"触发此工作的上游构建"也将链接到特定的$BUILD_ID.

在以下任一选项中

归档工件的配置是相对的$WORKSPACE.复制工件的
配置与"存档位置"相关,即. 由于"复制工件"与"存档位置"相关,而"存档位置"是相对的,因此对于所有密集目的,两种配置的相对路径可以相同且相对于$JENKINS_HOME/jobs/$JOB_NAME/builds/$BUILD_ID/archive/
$WORKSPACE$WORKSPACE

选项1

• 首先使用构建后操作存档工件,否则您无需复制.
  1. 如果您的文件位于根目录中$WORKSPACE,则应为:(
     PROJECTNAME-*/**/*.jar,PROJECTNAME-*/**/*.zip
     注意,此处不是完整路径)
• 然后Upstream Build that triggered this job用于复制工件选择.
  1. 对于Artifacts复制字段使用:
     
     • ** 或空白以复制所有存档的工件,或
     • PROJECTNAME-*/**/*.jar,PROJECTNAME-*/**/*.zip (与归档部分相同)

选项2

如果您不想存档,可以$WORKSPACE直接使用Copy from workspace of latest completed build,但是必须确保在执行下游构建时不能运行第二个上游构建,否则您可能会从部分构建中获取部分文件,因为如前所述,$WORKSPACE很不稳定.

• 同样,对于Copy Artifacts步骤,在Artifacts to copy字段下,使用path relative $WORKSPACE,即:
  PROJECTNAME-*/**/*.jar,PROJECTNAME-*/**/*.zip

选项3

如果您确实要在不同作业之间复制整个WORKSPACE,请使用其中一个

• 克隆工作区SCM插件或
• 共享工作区插件