介绍
Walk Weekender 已确认 Riverwalk Saturday 访客资料包的一个版本。之后的一个草稿版本也已构建成功。交付任务必须从现有的 Jenkins 运行中取得已确认的资料包，不能重新构建，也不能依赖已经清空的工作区。
本实验要求你掌握保留可下载的活动资料包中讲解的归档、工作区清理和指纹概念，以及 Jenkins 的基本页面操作和 ZIP 解压。这个单元独立初始化：源构建历史、当前使用的较早版本资料包和交付任务都已准备好。你不需要前一个实验的文件或仍在运行的 VM。
使用 Pack Desk 检查实际的访客文件，使用 Jenkins 查看和配置任务。这是同一台已准备好的 VM 中的两个服务。Copy Artifact 插件已可使用。提供的发布程序是一个小型本地训练接收端，用于检查本次请求；它不是生产环境的构建产物仓库或审批服务。你将选择一个已经确认的运行，而不是实现审批流程。预计用时由作者估算，未经初学者实测。
对照请求与复制的资料包
在这一步中，你将识别已确认的源运行，然后观察交付任务如何复制了另一个版本。请从 Pack Desk 开始。
阅读 Requested edition: RW-02。活动为 Riverwalk Saturday，源任务为 create-riverwalk-pack。选择 Open the current pack。当前版本为 RW-01，集合时间为 10:30。请求的资料包应替换这个较早版本，同时保持独立的 Parkside 资料包可用。使用浏览器的 Back 操作返回资料台。
切换到 Jenkins，打开 create-riverwalk-pack，查看 Builds 下带编号的构建。构建编号属于某一个任务，仅凭编号无法在全局唯一标识构建产物。打开每次构建的 Console Output，阅读已准备的访客版本和最终结果。历史包含：
| 构建 | 访客版本 | 结果 | 对本次请求的含义 |
|---|---|---|---|
| #1 | Parkside Paper Trail / PP-01 | SUCCESS | 另一项活动 |
| #2 | Riverwalk Saturday / RW-02 | SUCCESS | 现有的已确认资料包 |
| #3 | Riverwalk Saturday / RW-03-DRAFT | SUCCESS | 较新的草稿，并非请求的版本 |
| #4 | Riverwalk Saturday / RW-02 | FAILURE | 未成功的运行，尽管保留了 ZIP |
通过面包屑导航链接打开构建 #2，下载 Build Artifacts 下的 event-pack.zip，并解压完整归档。概览和须知显示 RW-02 和 10:00。控制台输出以工作区清理结束。归档属于该构建，因此交付任务在清理后仍能取得它。
保留现有的源构建历史。不要配置、重新运行、删除或重命名源任务及其构建。允许修改的范围仅限 deliver-riverwalk-pack Pipeline 及其构建参数。保留提供的文件、发布程序、归档和清理操作，并完整保留独立的 Parkside 资料包。
使用 Dashboard 面包屑导航，打开 deliver-riverwalk-pack，然后选择 Configure 和 Pipeline 区域。阅读 Copy archive 阶段，暂时不要修改：
copyArtifacts projectName: params.SOURCE_JOB,
selector: lastSuccessful(),
filter: 'event-pack.zip',
fingerprintArtifacts: true
copyArtifacts 从另一个 Jenkins 任务取得已保留的构建产物。projectName 选择该任务；params.SOURCE_JOB 读取本次交付运行输入的值。filter 选择归档中的文件。选择器决定使用哪一次带编号的源运行。lastSuccessful() 是一种随构建历史变化的选择方式：它表示复制发生时最近一次成功的运行，而不是请求中的版本。fingerprintArtifacts: true 记录文件使用情况，以便在任务之间追踪。
提供的 Archive delivery 阶段会在交付构建上保留复制的 ZIP。Deliver pack 将复制所得的原样字节发送到本地资料台。最后的 post 清理会清空交付工作区。保持这些部分不变。不做编辑，直接选择 Save。
选择 Build with Parameters。等待表单加载完成。将 SOURCE_JOB 设为 create-riverwalk-pack，将 SOURCE_BUILD 设为 2，然后选择 Build。这些值描述了预期的来源，但当前选择器仍然忽略 SOURCE_BUILD。
等待本次交付构建以 FAILURE 结束，然后打开 Console Output。预期会看到 Copied 1 artifact，来源为构建 3，随后出现 **The package bytes differ from the selected source archive.**。发布程序返回 HTTP 422：已连接到服务，但服务拒绝了选定的软件包。这与连接失败不同。shell 步骤报告非零结果，因此构建失败。
打开本次交付构建的 Build Artifacts 中的 event-pack.zip，将它解压到单独的文件夹，并阅读概览。其中包含 RW-03-DRAFT，因为构建 #3 是最近一次成功的源运行。保留的 ZIP 和绿色的源运行状态，并不足以识别请求的版本。
切换到 Pack Desk，刷新并再次打开当前资料包。它必须仍显示 RW-01 和 10:30。被拒绝的尝试不能替换有效的访客资料。使用浏览器的 Back 操作返回资料台。
交付并追踪已确认的运行
在这一步中，你将复制明确指定的已确认运行，并验证交付的访客文件及其 Jenkins 追踪记录。请从 Jenkins 中的 deliver-riverwalk-pack 任务页面开始。
选择 Configure，然后选择 Pipeline。在 Script 中，仅将：
selector: lastSuccessful(),
改为：
selector: specific(params.SOURCE_BUILD),
specific(...) 选择一个明确的源构建编号。params.SOURCE_BUILD 读取构建表单中输入的字符串，与 SOURCE_JOB 一起标识一个现有运行。保留逗号：后面的 filter 设置属于同一个 copyArtifacts 操作。保留提供的 RECEIVER_URL 值、所有其他阶段以及最后的清理操作。
在 Script 中找到 Copy archive 下的选择器行。等待代码加载完成，必要时在编辑器内部滚动。双击 lastSuccessful，仅选中这个函数名，然后输入 specific。空圆括号会保留下来。将插入光标放在 specific 后面，按一次 Right Arrow 键移入 ()，然后输入 params.SOURCE_BUILD。保存前，对照上面的完整选择器行检查。如果不慎替换了更多文本，请在保存前于 Windows/Linux 上使用 Ctrl+Z，或在 macOS 上使用 Command+Z，然后重试。选择 Save。
再次运行 Build with Parameters。等待表单加载完成，为 SOURCE_JOB 输入 create-riverwalk-pack，为 SOURCE_BUILD 输入 2，然后选择 Build。等待 SUCCESS。控制台应显示复制的构建产物、归档和指纹操作、包含 delivered 的响应，以及最后的工作区清理。
如果 Jenkins 报告 Groovy 语法错误，请返回 Configure，对照上面的准确替换内容检查选择器行、圆括号和逗号。保存，并使用相同值再次运行。如果控制台报告找不到项目、构建或构建产物，请检查两个表单值和源构建 #2。不要通过重新运行源任务来制造一个新运行。响应 The selected source run does not satisfy this delivery request. 表示任务或构建编号有误。The package bytes differ from the selected source archive. 表示复制的 ZIP 与这些参数指定的源运行不匹配。两者都是已连接到资料台后发生的业务拒绝。
打开成功交付构建的状态页面，选择 See Fingerprints。在 Recorded Fingerprints 中，event-pack.zip 所在行的 Original owner 必须指向 create-riverwalk-pack 的构建 #2。选择 event-pack.zip 链接打开详情。表示首次引入该文件的构建链接应标识这次源运行，且 Usage 必须包含你成功的 deliver-riverwalk-pack 运行。这些是 Jenkins 对同一文件来源和使用情况的记录，不能证明谁批准了某个版本，也不提供发布者的密码学签名。
阅读页面顶部附近表示首次引入该文件的构建链接，以及 Usage 下的两个任务。你的交付构建编号可能与示例不同。
从这次成功的交付构建下载 event-pack.zip。将它解压到一个新文件夹，打开 index.html，确认 Riverwalk Saturday、RW-02 和 10:00。打开 Explore the route，检查全部三个站点和渲染出的路线图片。选择 Download all route stops 获取 CSV，选择 Read the visitor notes 查看本地文本。须知可能会直接在浏览器中打开，而不是再次触发下载；原始文本文件已在解压后的文件夹中。将全部八个文件保持在一起，包括 build.json，其中的 job 和 number 分别标识 create-riverwalk-pack 和 2。
切换到 Pack Desk 并刷新。当前资料包现在必须显示 RW-02。打开它，重复路线、CSV 和须知检查。使用浏览器的 Back 操作返回，然后选择 Download the current ZIP。下载的必须是完整的原始源归档，而不是新构建的替代品。接收端会在更改当前资料包前比较实际字节。
最后，从资料台导航中选择 Parkside pack，确认 Parkside Paper Trail 仍能打开，并包含路线和须知。源构建历史和所有提供的文件必须保持完整。此后每次编辑 Pipeline，都要先重新运行已保存的 Pipeline，再检查是否完成。
总结
你在工作区清理之后，从现有的 Jenkins 构建中取得了已确认的访客资料包。你了解了随历史变化的选择器为什么可能选中构建成功的草稿，使用了明确的任务和构建编号，并通过 Jenkins 指纹追踪原始归档如何被独立的交付任务使用。资料台现在提供完整的原始访客文件，同时另一项活动仍然可用。
