Jenkis下游作业无法找到上游工件 [英] Jenkis downstream job fails to find upstream artifacts

问题描述

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

The setup is used to build and deploy to Adobe AEM.

主构建作业从git存储库中提取，构建和打包，运行测试，然后触发应使用上游作业中已构建软件包的下游作业.

Master Build job pulls from git repository, builds and packages, run the tests and then fires downstream jobs that should use the built packages from upstream job.

问题在于下游作业失败，并显示以下消息:

The issue is that downstream job fail with the message:

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插件正在寻找错误位置的工件.正确的位置应该是

It seems to me that somehow CopyArtifacts plugin, triggered by the downstream job, is looking for the artifacts in wrong location. The correct location would be

/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

下游作业从另一个项目复制工件，然后该生成是触发此作业的上游生成"或从最新完成的生成的工作区复制".而且都行不通.

The downstream job copies artifacts from another project, and then the build was either "Upstream build that triggered this job" or "Copy from workspace of latest completed build". And none works.

有什么想法吗?

推荐答案

TL; DR

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

TL;DR

You are trying to use artifacts without archiving them first.
You are trying to use absolute paths, but they should be relative to $WORKSPACE and/or "archive location".

您误解了与詹金斯有关的人工制品"的概念.

You are misunderstanding the concept of "Artifacts" as it relates to Jenkins.

工件是在构建后归档并借助归档工件后生成操作而专门保留的文件.

Artifacts are files that are specifically preserved after the build with the help of Archive the Artifacts post-build action.

构建运行时，它将在以下范围内运行:
$WORKSPACE，通常在文件系统上驻留在
$JENKINS_HOME/jobs/$JOB_NAME/workspace
在其中，您可以拥有SCM检出文件夹，临时构建文件，最终构建文件，二进制文件等.

When the build runs, it runs within:
$WORKSPACE, which on filesystem usually resides within
$JENKINS_HOME/jobs/$JOB_NAME/workspace
Inside there, you can have your SCM checkout folders, temporary build files, final built files, binaries, etc.

$WORKSPACE的内容是易变性，在构建时间范围之外(并且下游作业在构建时间范围之外)，您永远不要依赖它. $WORKSPACE的内容在不同的主/从节点之间可能有所不同，可以随时通过admin或SCM更新/清除/签出将其删除.

The contents of $WORKSPACE is volatile, you should never rely on it, outside of the build timeframe (and downstream jobs are outside of the build timeframe). The contents of $WORKSPACE could be different between different master/slave nodes, it could be deleted at any time by admin, or by SCM update/cleanup/checkout.

了解整个职位中只有一个 $WORKSPACE也是很重要的.

It's also important to understand that there is only one $WORKSPACE for the whole Job.

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

But now pay attention to your Build History, there are several entries in that list, referenced by build number (#) and date timestamp. These are stored under:
$JENKINS_HOME/jobs/$JOB_NAME/builds/$BUILD_ID
with $BUILD_ID being the date-timestamp of the build, like 2014-10-22_11-33-46

$WORKSPACE包含与 当前或最后 相关的信息(问题是:您无法确定它是当前"还是最后")构建；
builds文件夹包含所有过去(保留)构建执行的记录(这是组成您左侧的构建历史列表的内容)， 每个构建 .

The $WORKSPACE contains the information relevant to current or last (and the problem is: you can never be sure if it's "current" or "last") build;
The builds folder contains a record of all past (retained) build executions (this is what makes up the Build History list on your left), per build.

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

By default, it contains only what Jenkins itself needs: build.xml copy, changelog information, console log. When you go to URL http://$JENKINS_URL/job/$JOB_NAME/[nn]/ where [nn] is a numeric job build/run number (#), it's reading this information from the builds folder on the filesystem.

要保留构建的工件(避免它们被下一个构建所覆盖，消除后遗症或只是访问较早的构建)，您需要归档工件(具有相同的后缀-制作具有相同标题的动作).归档工件时，您指出要保留$WORKSPACE中的哪些文件.当詹金斯(Jenkins)进行归档时，它将把这些文件(保留[相对于$WORKSPACE的路径]保留)放入:
$JENKINS_HOME/jobs/$JOB_NAME/builds/$BUILD_ID/archive/.
这样，您可以为先前的版本保留多组工件，而不仅仅是$WORKSPACE中的最新/最后".

To preserve artifacts of a build (to avoid them being overwritten by the next build, wiped out worskpace, or just to access older builds), you need to Archive the Artifacts (with same post-build action with the same title). When you archive the artifacts, you indicate which files within $WORKSPACE you want to preserve. When Jenkins does the archiving, it will place those files (keeping paths [relative to $WORKSPACE] preserved) into:
$JENKINS_HOME/jobs/$JOB_NAME/builds/$BUILD_ID/archive/.
This way, you can have multiple sets of artifacts preserved for previous builds, not just "latest/last" from $WORKSPACE.

出于完整性考虑，我将提到Jenkins的永久链接"(例如http://$JENKINS_URL/job/$JOB_NAME/lastSuccessfulBuild和/lastFailedBuild等)实际上是文件系统上指向保留的builds/$BUILD_ID文件夹之一的符号链接.

For the sake of completeness, I will mention that Jenkins's "permalinks", such as http://$JENKINS_URL/job/$JOB_NAME/lastSuccessfulBuild and /lastFailedBuild, etc are in fact symlinks on the filesystem to one of the preserved builds/$BUILD_ID folders.

最后，您可以通过在作业配置上使用舍弃旧版本" 复选标记来控制运行多少版本以及保留(可以单独配置)多少工件.默认情况下，所有内容都会保留，但是如果您开始保留工件，则需要考虑硬盘空间容量.

Lastly, you control how many build runs and how many artifacts are retained (can be configured separately) through "Discard old builds" checkmark on job configuration. By default, all are retained, but if you start retaining artifacts, you need to think of hard-disk space capacity.

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

So with the information above, and looking at your error messages, you should now see that the Copy Artifacts plugin is correctly looking for artifacts under the /archive/ section of a build.

您还应该注意，复制工件插件不会不允许您在选择要复制的内部版本时选择当前内部版本".它具有永久链接(例如上次成功"或上次构建")和特定的内部版本号，所有这些都转换为$JENKINS_HOME/jobs/$JOB_NAME/builds/$BUILD_ID/archive/

You should also notice that Copy Artifacts plugin does not let you pick "current build" when selecting which build to copy from. It has permalinks (like "last successful" or "last build"), and specific build numbers, all of which translate to preserved builds under $JENKINS_HOME/jobs/$JOB_NAME/builds/$BUILD_ID/archive/

即使触发此任务的上游版本"也将链接到特定的$BUILD_ID.

Even "Upstream Build that triggered this job" will link to a specific $BUILD_ID.

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

Configuration for Archiving Artifacts is relative to $WORKSPACE.
Configuration for Copy Artifacts is relative to "archive location", that is $JENKINS_HOME/jobs/$JOB_NAME/builds/$BUILD_ID/archive/.
Since "Copy Artifacts" is relative to "archive location", and "archive location" is relative to $WORKSPACE, then for all intensive purposes, the relative paths of both configurations can be same and relative to $WORKSPACE

• 首先使用构建后操作将工件存档，否则，您没有任何可复制的内容.

• First Archive the Artifacts with the post-build action, otherwise you have nothing to copy from.

1. 如果您的文件位于$WORKSPACE的根目录中，则应为:
   PROJECTNAME-*/**/*.jar,PROJECTNAME-*/**/*.zip
   (请注意，此处没有完整的路径)

1. If you have your files in the root of $WORKSPACE, it should be:
   PROJECTNAME-*/**/*.jar,PROJECTNAME-*/**/*.zip
   (Note, not full paths in here)

然后将Upstream Build that triggered this job用于复制工件选择.

Then use Upstream Build that triggered this job for Copy Artifacts selection.

1. 对于要复制的工件字段，请使用以下任一方法:
   
   • **或空白以复制所有已归档的工件，或者
   • PROJECTNAME-*/**/*.jar,PROJECTNAME-*/**/*.zip(与归档部分相同)

1. For Artifacts to copy field use either:
   
   • ** or blank to copy all archived artifacts, or
   • PROJECTNAME-*/**/*.jar,PROJECTNAME-*/**/*.zip (same as the archiving section)

如果您不想存档，则可以直接将$WORKSPACE与Copy from workspace of latest completed build， 一起使用，但是必须确保在执行下游构建时没有第二个上游构建可以运行，否则您可以冒着从部分构建中获取部分文件的风险，因为如前所述，$WORKSPACE是易失的.

If you don't want to archive, you can use $WORKSPACE directly, with Copy from workspace of latest completed build, however you must ensure that no second upstream build can run while downstream build is executing, else you risk getting a partial file from a partial build, because as previously explained, $WORKSPACE is volatile.

• 同样，对于复制工件步骤，在要复制的工件字段下，使用相对于$WORKSPACE的路径，即:
  PROJECTNAME-*/**/*.jar,PROJECTNAME-*/**/*.zip

• Again, for the Copy Artifacts step, under Artifacts to copy field, use path relative to $WORKSPACE, that is:
  PROJECTNAME-*/**/*.jar,PROJECTNAME-*/**/*.zip

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

If you really want to copy the whole WORKSPACE between different jobs, use either

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

这篇关于Jenkis下游作业无法找到上游工件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！