我是Aure DevOps的新手。尝试创建构建和发布管道有一件我不了解的事情:
常见的是,每种构建最终都会产生一些输出,称为工件。
使用Azure DevOps似乎总是需要最终复制或发布任务,才能将创建的工件从A复制到B,因此发布任务然后可以访问编译的工件。
为什么这些工件不能从构建它们的位置直接供发布管道使用?为什么构建任务没有自动设置指向正确文件夹的变量,以便发布管道可以从那里直接访问文件?
这是否已经发生,我只是在观看的教程中缺少一些东西?
答案 0 :(得分:1)
原因很多。
两个简单的方法:
答案 1 :(得分:0)
为什么发布管道无法轻松访问这些工件 就在它们的建造地?
同意丹尼尔。
对我来说,主要原因是因为我们不能一直持有托管代理。由于MS希望有效地保护资源,因此它不会占用很长时间。
当我们排队等待构建时,MS将为我们分配一个全新的干净代理来执行我们的任务,并且在构建完成后,MS将回收分配给我们构建的代理并将代理恢复到其初始状态以进行准备接受下一个任务的分配。
因此,我们无法保持托管代理在下一个发布管道中使用它。我们必须将工件存储在云/服务器中,然后才能在发布管道中将其下载。否则,我们无法从已还原的代理中获得所需的工件。
此外,MS是随机分配给该代理的,我们不能保证在发布管道中会分配和构建相同的代理。
这是我们需要复制或发布工件的主要原因。
如果您不想复制或发布工件,则可以设置自己的私有代理,并且在执行发布管道之前不要清除代理。
更新:
为什么用户会费心寻找文物的位置 手动?我本来希望每个构建管道都附带一个 个人空间来存储最新的构建工件。一个空间 Azure DevOps自动将构建工件复制到其中。对我来说 看起来必须手动将内容从A复制到B,然后 从B到C。
因为不需要全部输出,例如测试项目,所以我们需要的是测试项目的测试结果/代码覆盖率,而不是解决方案的输出。在这种情况下,我们不需要将输出复制到工件。另一方面,我们需要将一些特殊文件复制到工件中,然后自动复制构建工件将无法满足您的要求。
这也是我们提供将文件复制到工件的任务的原因,以便我们可以自定义个性需求。
当然,如果您认为手动复制是多余的,则可以使用MSBuild参数/p:output=$(build.artifactstagingdirectory)
将输出直接设置为工件。
如果我需要在Build管道中将内容从A复制到B,那么 应该阻止我立即将其复制到C?然后单独 如果不是多余的话,发布管道将是可选的。
如果您处于构建管道中,则还有另一个任务Download build artifacts,该任务可以下载构建工件。
如果您处于发布管道中,则只需选择构建工件作为源,发布管道将自动下载该工件:
检查this document了解更多详细信息。
希望这会有所帮助。