自托管 azure 代理 - 如何配置管道以共享相同的构建文件夹

Posted 2023-02-18

【中文标题】自托管 azure 代理 - 如何配置管道以共享相同的构建文件夹

【英文标题】：Self hosted azure agent - how to configure pipelines to share the same build folder

【发布时间】：2020-09-30 02:44:16

【问题描述】：

我们在本地服务器上有一个自托管的构建代理。

我们通常有一个庞大的代码库，过去在 TFS2013 构建代理中遵循这种机制：

每日签到已构建到 c:\work\tfs\（大约需要 5 分钟） 每晚都会运行一个批处理文件，对这些文件夹执行相同的构建，使用相同的源（它们已经是 CI 构建中的“最新”），并构建安装程序。将文件复制到网络位置，并向团队发送电子邮件，详细说明构建成功/失败。 （大约需要 40 分钟）

关键在于，对于每晚构建，无需获取最新的源代码，所需的磁盘空间也不会增加太多。仅由安装程序尺寸决定。

为了使用 Azure Devops 复制这一点，我创建了两个管道。 在经典编辑器中使用 MSBuild 任务执行 CI 的一个管道 - 效果很好 经典编辑器中的另一个管道运行我们现有的 powershell 脚本，安排在晚上 9 点 - 效果很好

但是，即使我的代理不支持并行构建，正在发生的事情是： CI 管道的文件夹是 c:\work\1\ Nightly 构建文件夹是 c:\work\2\

这使我们需要的磁盘空间量翻了一番（10gb 到 20gb） 它们是相同的代码文件，只是构建方式不同。

我一直在努力寻找一种方式对代理说“请为所有管道使用相同的源文件夹”

这是什么设置，否则我们必须向服务提供商支付额外的 GB 存储空间。

或者我是否需要将我的经典管道更改为 Yaml 并以某种方式有条件地分支构建，以便它知道它正在被安排并做一些不同的事情？ 或者，停止使用 Pipeline 进行计划构建，并像以前一样在 Windows 中使用任务计划程序？

（我确实尝试过寻找同样的问题 - 我确定我不能是唯一的问题）。

【参考方案1】：

有“workingDirectory”指令可用于在管道中运行脚本。这个链接有这个细节 - https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/command-line?view=azure-devops&tabs=yaml

【讨论】：

有趣——即使这不起作用，你也让我重新思考我在做什么。仅仅因为我的 power shell 脚本使用相对路径运行，我没有理由不能对其进行硬编码以检测它正在以 2/s 运行并强制它翻转到 1/s - 我会试一试，谢谢.

【参考方案2】：

您的构建代理中工作文件夹c:\work\1\、c:\work\2\...c:\work\6\ 的编号“1”“2”...“6”代表特定管道。

Agent.BuildDirectory

代理上的本地路径 给定构建的所有文件夹 管道已创建。此变量的值与 管道.工作区。例如：/home/vsts/work/1

如果你有两个管道，也会有两个对应的工作文件夹。这是一种例外行为。我们无法将管道配置为共享相同的构建文件夹。这是设计的。

如果您需要使用更少的磁盘空间来节省成本，害怕停止使用管道进行计划构建，并且像以前一样在 Windows 中使用任务计划程序是更好的方法。

【讨论】：

感谢您的意见，但这并不能真正推动我们走向未来。当源代码控制指令相同时，能够强制管道与同一代理上的另一个管道共享相同的构建目录 - 这将是加速构建的绝佳设计功能。可惜它被设计出来了。我将尝试将我的 PowerShell 脚本更改为另一个管道的目录。

@GilesDMiddleton 感谢您的友好更新。我们试图使文件夹结构更加简洁明了。每个管道对应不同的文件夹将易于管理下载构建源、构建日志、生成的构建文件。所有更改都封装在每个管道中，不会相互干扰。但是，如果您找到了解决方法，请随时在此处分享，这可能会对社区中的其他人有所帮助。