问题标签 [vnext]

可以为拉取请求构建设置的最激进的构建保留策略在“清理拉取请求构建”中进行了描述

保持最少 0 次构建的策略

尽管如此，这意味着成功的 PR 构建（没有人永远需要的工件）只会在下一次自动保留清理之后被删除 - 通常是第二天，但实际上它会导致近两天不再需要的构建。

在我们的特殊情况下，似乎需要找到一种方法来尽快清理成功的 PR 构建，因为它们的频率和工件的庞大规模可能会周期性地使我们尚未完全组织起来的专用于 PR 处理的基础设施紧张（它将得到显着改进，但不会只要我们愿意，那些成功的公关构建仍然不会减少）。

据我所知，唯一的方法是手动删除构建。

虽然实现起来并不难，但我仍然想检查是否有更简单的标准方法可以自动删除成功的 PR 构建。

PS：在我们高度定制的构建过程中有一个特殊性——我们有多个依赖的工件。像创建 A 一样，使用它来构建 B，创建 C 来测试 B ......因此，尝试不使用下面建议的自定义条件在整体成功构建上发布工件并不完全可行。

According to https://docs.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=tfs-2018

These variables are automatically set by the system and read-only. (The exceptions are Build.Clean and System.Debug.)

Nonetheless, if one tries to create a vnext build with the following tasks

1. Inline Powershell - Write-Host $env:BUILD_SOURCEVERSION
2. Inline Powershell - Write-Host ("##vso[task.setvariable variable=build.sourceversion;]"+'someNewValue')
3. Inline Powershell - Write-Host $env:BUILD_SOURCEVERSION

Task 2 won't fail, and the last task will output something like

2018-10-24T07:37:23.1232438Z someNewValue

instead of the expected original source version (the value printed in the first task).

So,

1. Either I am misreading the docs / they are unclear on that account
2. Or is it some genuine defect in TFS that one should pursue with MS?

我看到在 CI 构建中获取源代码时使用 Shallow Fetch 的想法，因为它只获取每个文件的最新版本。

但我更怀疑何时进行多次修订。

你什么时候使用 Shallow Fetch > 1 或者根本不使用它？

我的问题是关于 vNext/Octopus 进程与基于 XAML 的进程的可维护性。或者更确切地说，因为不可能保持他们的理智让我相信我们正在做一些非常错误的事情。

鉴于：

• 微软推动逐步淘汰其 TFS XAML 构建以支持 vNext 构建
• Octopus Deploy 是一个流行的部署自动化框架
• 我们有许多基于 XAML 的构建，但开始移植到 vNext
• 使用 Octopus Deploy 自动部署

具体来说，我们在 QA 中进行了三种构建：

• 旧的基于 XAML 的编译生成生成要部署的工件
  • 最终只是构建代码，将其压缩并放置在众所周知的位置
• 新的 vNext 编译构建生成要部署的工件
  • 和上面一样
• 部署构建
  1. 每个部署环境的基于 XAML 的构建定义。这是特定部署的真实来源，包含所有配置 URL、连接字符串、证书指纹等。构建定义有 100 多个构建参数。每次设置新环境时，我们都会克隆现有的 XAML 构建定义并更改参数。
     • 此构建解压构建工件，根据配置参数生成所有 web/app 配置文件，并使用 octo.exe 启动带有大量参数的 Octopus Deploy 并等待结束
  2. 八达通部署流程
     • 从先前由 XAML 构建解包的构建工件创建 3 个包，以匹配三个部署区域 - Web 场、后台作业引擎集群和数据库
     • 将相关包裹递送至相关触手。
     • 触手解包并设置它们各自的包

因此，如果我们有 50 个部署环境，那么我们就有 50 个 XAML 部署构建，每个构建都捕获各自环境的上下文。但是 XAML 部署构建将部署工作委托给 Octopus，在这里我们被迫拥有 50 个 Octopus 项目 - 每个部署一个。

为什么会这样？我们研究了仅拥有一个 Octopus 项目的选项，但该项目的发布版本是什么？为了让我们能够在海量版本中导航，发布版本必须包括：

• 已部署代码的构建版本，例如55.0.18709.3
• 部署环境的名称，例如atwfm

使用上面的例子，这给了我们55.0.18709.3-atwfm，但有时我们想在同一个部署环境中部署相同的构建工件两次。但是唯一的 Octopus 项目已经有 release 了55.0.18709.3-atwfm，那么如何在不删除已经存在的 release 的情况下再次部署55.0.18709.3呢atwfm？

我们找不到解决方法，因此，我们每个部署都有 Octopus 项目。

这太疯狂了，因为 Octopus 项目更新起来很痛苦。假设我们需要添加一个步骤——在 50 个项目中进行。互联网上有很多建议使用自动化来编辑多个项目。一点都不理想。

vNext，顺便说一句，也有同样的问题。如果我要将现有的 XAML 构建移植到 vNext，我最终会得到 50 个 vNext 部署构建。如果我决定添加一个步骤，我需要在所有 50 个构建中都这样做！！！！

请注意，XAML 构建没有这个问题（尽管它们还有很多其他问题），因为它们的过程与参数是分开的。我可以修改一次工作流，所有 XAML 构建现在都使用新的流程更改进行更新。

我的问题是——人们如何使用 vNext 和 Octopus，因为我们的流程让我发疯。一定会有更好的办法。

编辑 1

我想澄清一下。我们有时想要两次部署相同的构建工件。我们不会重新编译它们并重用相同的版本。不。我们已经有了方便的构建工件，构建版本在工件内部烘焙。我们可能希望第二次将其部署到同一环境中，因为例如，该环境中的某些数据库配置错误，现在已修复，我们需要重新部署。这并不意味着我们可以重新运行已经存在的 Octopus 版本，因为修复可能涉及调整相应 XAML 部署构建定义的部署参数。因此，我们可能会被迫重新启动 XAML 部署构建，它永远不会编译代码。

编辑 2

首先，为什么我们从 TFS XAML 构建而不是从 Octopus 驱动部署？历史原因。起初我们没有八达通。部署是由我们的临时代码完成的。当我们介绍 Octopus 时，我们决定保留 XAML deploymenet 构建有两个原因：

1. 为了节省将具有所有大量部署参数的所有 XAML 部署构建迁移到 Octopus 的成本。也许这是一个错误的决定，也许我们可以自动化迁移。
2. 因为 TFS 有更好的工具来显示测试结果。部署可能以部署冒烟测试结束，其结果必须在某处发布。我们看不到 Octopus 如何帮助我们发布结果，TFS 可以。

为什么要重新部署？例如，部署参数之一是证书指纹。更新证书时，必须更改此参数（我们确实可以自动更新 XAML 构建参数）。但我们经常发现它已经使用错误的指纹进行部署。因此，我们修复了部署并重新部署。或者，我们发现已部署应用程序的一些奇怪行为，并希望重新部署一些额外的跟踪/调试功能。

我有一个团队项目，并且在多个地理位置配置了构建和发布。由于所有地理位置都有自己的放置位置和代理。

所以我的问题是，在创建发布作业时必须选择发布代理池。那么，当我触发与该版本关联的构建时，是否可以动态更改此发布代理池？

场景：来自印度和美国的人可以运行构建作业（因为它很常见），构建是手动触发，所以我们可以自由选择印度或美国的构建代理池，但随后的发布是自动触发，所以是是否可以在各自国家的代理商中触发发布？

（例如，如果开发人员从印度运行作业，那么发布作业应该在印度的发布代理中运行，同样，如果有人从美国触发它，它应该在美国发布代理中触发）。

任何帮助，将不胜感激。

这是一个典型的构建摘要页面：

我想在这个页面的某个地方添加一条自定义消息，最好是在它自己的标题下。

怎么做到呢？

我的 vNext 构建包含很少的步骤 - 我只是设置了一些设置并调用主 Powershell 构建脚本，该脚本在内部调用 msbuild，但它也执行其他操作。

我知道 vNext 带有一个分布式 msbuild 记录器，它允许 msbuild 报告直到 vNext 的事件以显示在步骤 Timeline 中。

这可以为任意逻辑完成，而不仅仅是 msbuild？

编辑 1

我编写 vNext（或 Octopus）项目的理念是尽量减少步骤数。这是因为这些步骤都是代码，但是 vNext 和 Octopus 都没有提供我在编写代码时期望得到的环境，具体来说：

1. 版本控制
   • 从技术上讲，vNext 有它，但对我来说，VCS 意味着与其他版本很容易区分。vNext diff 充满了无关紧要的废话。仍然比章鱼好光年，章鱼没有。
2. 代码审查
3. 相关工作项（为什么 X 改变了 Y？）
4. 调试

对我来说，这些是必不可少的，这就是为什么我倾向于拥有一个主构建脚本。我确实将事情委托给 vNext (Octopus)——比如发布工件和测试或获取源代码。但是在本地特定机器上运行的代码是我的 Powershell 脚本。

似乎如果我的构建步骤产生了一个子进程，那么该进程将无法在构建结束后存活——它被杀死了。

但是我有一个场景，其中触发子进程以完成构建不应等待其完成的某些操作（向 Azure AppInsights 报告指标）。

此过程在 XAML 构建中运行良好，但现在我们迁移到 vNext，它被破坏了，因为子进程在构建结束时被终止。

可以做些什么呢？

我们的分支策略指定了 PR 验证构建。该构建在system.debugis时发布诊断二进制日志true。

但是这个参数的默认值是false. 在 XAML 构建中，我们可以使用显式搁置集触发 Gated Check-In 构建并覆盖构建参数的默认值。但是我看不到如何在 vNext 构建中为 Pull Request 做到这一点。

编辑 1

我不希望默认生成二进制日志。用例是当某人的 PR 构建失败并且失败的原因在构建日志中不是很明显。那是我希望能够将验证构建重新排队的时候system.debug = true

我有一个 vNext 构建，它运行一些 NUnit 测试并发布结果。但是，即使在相应的 XML 文件中找到了测试产生的输出，也不会发布。

例如：

但是，如果我检查相应的 XML 文件 - 它就在那里：

注意<output>元素。

我非常希望看到这个输出与测试结果一起发布。我该怎么做？

附言

出版还有另一个问题。运行持续时间在顶部窗格中报告为 4h 59m，但在底部详细信息窗格中它是正确的 10:48.176 分钟。4h 59m 看起来很像 5h，这是 EST 和 UTC 之间的时差。测试在 Octopus 服务器上运行，并由 vNext 构建获取。也许某处存在时区混乱。

编辑 1

我们有一个本地 TFS

编辑 2

检查Publish Test Results任务的源代码发现它使用Microsoft.TeamFoundation.TestClient.PublishTestResults程序集来解析 NUnit XML 测试结果。具体来说，以下 C# 代码用于解析test-case元素 (NUnit3ResultsXmlReader.cs)：

由此可以得出，汇编作者认为测试输出仅在有问题的测试用例失败时才有用。这是一个不幸的决定，因为输出何时有用不是由他们决定的。如果它在测试结果 XML 中，那么它应该被发布。

打开一个新问题https://github.com/Microsoft/azure-pipelines-tasks/issues/8979

打开 Azure DevOps 功能请求 - https://developercommunity.visualstudio.com/idea/432166/the-publish-tests-azure-devops-plugin-should-publi.html