更新：在以前的版本中，我错误地Assert匹配的哈希意味着匹配的文件名。这是错误的，因为指纹的fileName条目代表哈希的 * 第一次出现 * 的基础。
看起来指纹识别不仅有缺陷，而且显然不是用来检查完整性或本地文件的，而只是用于 * 跟踪 * 对工件的访问。
除了文件名由于相同的哈希值而丢失之外，文件夹的详细信息也被省略了，所以即使没有模糊的文件名，您也可以得到完全误导的结果。
使用以下管道片段创建一些具有固定内容/哈希的文件，并将它们存储为工件：

sh("rm -rf ${WORKSPACE}/build") // cleanup
dir("${WORKSPACE}/build") {
    sh("""
        mkdir folder1
        mkdir folder2
    
        echo one   > file_a
        echo two   > file_b
        echo two   > file_c           # same content, different name

        echo three > folder1/file_d 
        echo one   > folder1/file_e   # same content, different folder
        echo four  > folder1/file_a   # different content, different folder, but same name
    
        echo one   > folder2/file_a
        echo four  > folder2/file_b
        echo three > folder2/file_d
    """)
}

archiveArtifacts(artifacts: "build/**", fingerprint: true)

字符串
比较实际的工件名称和指纹数据，你会得到这样的东西：
| 指数|工件名称|内容|指纹|
| --|--|--|--|
| 0 |build/file_a个|one个|file_a：5bbf5a52328e7439ae6e719dfe712200|
| 1 |build/file_b个|two个|file_b：c193497a1a06b2c72230e6146ff47080|
| 2 |build/file_c| two个|file_b：c193497a1a06b2c72230e6146ff47080|
| 3 |build/folder1/file_a个|four个|file_a：75ffdb827341e578959bfcabde3789d8|
| 4 |build/folder1/file_d个|three个|file_d：febe6995bad457991331348f7b9c85fa|
| 5 |build/folder1/file_e个|one个|file_a：5bbf5a52328e7439ae6e719dfe712200|
| 6 |build/folder2/file_a个|one| file_a：5bbf5a52328e7439ae6e719dfe712200|
| 7 |build/folder2/file_b| four| file_a：75ffdb827341e578959bfcabde3789d8|
| 8 |build/folder2/file_d| three| file_d：febe6995bad457991331348f7b9c85fa|
正如您所看到的，指纹列表中的fileName条目并不代表工件文件名，而只是第一次使用该散列进行指纹识别的工件的基本目录（即没有目录）！
然而，看起来工件的 * 排序 * 列表和指纹的 * 未排序 *（即原始顺序）列表仍然对齐，因此您可以逐个获取工件名称和指纹哈希。
工件列表必须进行排序，因为工件文件名和指纹的文件名排序不同。对我来说，sorted(artifacts)的顺序与fingerprints相同。
这是我如何创建一个从（完整的）工件名称到哈希值的Map：

fingerprint_url = f"{build.url}api/json?tree=fingerprint[hash]"
artifact_hashes = dict(
    zip(
        sorted(build.artifacts),
        (fprint["hash"] for fprint in client._session.get(fingerprint_url).json()["fingerprint"]),
    )
)

型