在现有 PUBLIC Azure DevOps 扩展中重命名 Azure Pipeline 任务

Question

我有许多 Azure DevOps 扩展。一些最近的任务，但也可以追溯到 2015 年，当时构建任务的可扩展性模型首次出现。随着时间的推移，Azure Pipeline Land 发生了很大变化......

当我们从基于 UI 的管道迁移到基于 YAML 的管道时，发生了最大的变化。一些隐藏的任务内部结构暴露了出来。

在过去，用户实际上只能看到Task's Friendly Name 和Description，而Team Foundation Server 将通过其TaskID 跟踪任务的真实身份，这是一个永远不会更改的GUID。

请看下面的示例：

  "id": "3ca44a28-62de-4c60-8d77-a99065b95a8a",
  "name": "VariableSetTask",
  "friendlyName": "Set Variable",
  "description": "Sets a variable.",
  "author": "Jesse Houwing",

随着 TFS 2017 的发布，可以将任务打包到一个扩展中，这会导致创建另一个标识元素、扩展的发布者、扩展 ID 和贡献 ID：

{
  "id": "jessehouwing-vsts-variable-tasks",
  "name": "Variable Toolbox",
  "publisher": "jessehouwing",
  "contributions": [
    {
      "id": "vsts-variable-set",
      "properties": {
        "name": "vsts-variable-set"
      }
    }
  ]
}

这些元素在基于 UI 的管道时代也被隐藏起来，但在 YAML 出现时也浮出水面。

steps:
- task: jessehouwing.jessehouwing-vsts-variable-tasks-dev.vsts-variable-set.VariableSetTask@2

如您所见，无论您是否通过“查看 YAML”按钮插入它们，现在都使用发布者、extensionid、contributionId 和 TaskName 来引用任务：

使用 YAML 助手时，仅当您在组织中注册了 2 个具有相同 TaskName 属性的任务时才会发生这种情况。

由于这些值现在是公开可见的，我想摆脱我过去使用的一些不好的命名：

• 去掉贡献ID中的vsts-
• 从 TaskName 属性中删除 Task
• 将所有内容设为小写以匹配 Microsoft 自己的任务
• 如果我能更新 ExtensionId，我会更喜欢它，它仍然引用 vsts-。
• 并从 extensionId 中删除 jessehouwing。

更改名称当然会对现有 YAML 用户产生影响，因为所有任务都是按名称引用的，而不是按 Id 引用，但它会使我的任务更容易用于新用户和从基于 UI 的管道转移到 YAML 的用户。

不幸的是，市场上有一些保护措施可以防止人们劫持其他人的扩展程序。这对任务的 ID：Guid 执行了许多操作。

• 对于在扩展中发布的任务的所有版本，Guid 必须相同（为了向后兼容，可以在单个扩展中发布 v1、v2、v3 等 vsix，以便用户在从 A 移动到 B 时进行选择.
• Guid 只能在一个公共扩展中发布（对私有扩展没有限制）。
• 由于某种原因，Guid 与 ContributionId 相关联，无论何时更改 ContributionId，都必须更改 TaskID。
• 您不能同时更改 TaskID 和 TaskName。

这实质上阻止了人们更改任务的公共身份，一旦发布在扩展中似乎。当您尝试时，市场将无法验证您的扩展并显示错误消息：

ERROR: Contribution Microsoft.VisualStudio.Services.TaskId.VARIABLE-TRANSFORM is re-using task ID of some other contribution from earlier version. 
To publish the extension, change the task ID.

或

ERROR: All the task versions belonging to Contribution variable-transform should have the same task id. 
The tasks at variable-transform/v1 (version 1.4.41) and variable-transform/v2 (version 2.0.41) do not have the same ids.

我看到的一种可能的解决方法是发布具有新 ID、新贡献 ID、新任务 ID 和新任务名称的新扩展，但这需要管理员批准并将新扩展安装到 6000+扩展的用户。这是一个不可能的问题。

我可以接受 ExtensionId 将无法修复，只需将新任务添加到现有扩展中，包括新名称、新 ID 等等，但这会破坏所有基于 UI 的自动更新功能用户（我无法遥测其中有多少），我的猜测是很多，因为我的许多任务都提供了一个 UI，使使用脚本和命令行更容易。从一个扩展无缝升级到下一个扩展的能力是我过去花费大量时间的事情之一。例如，在将可变任务从 v1 升级到 v2 时，Adding aliases 和输入字段的合理默认值会引起最小的麻烦。

请看下面的例子：

输入类型从输入字段更改为下拉列表，YAML 表示更改为多个字段的小写字母，并且根据下拉列表中的反映值出现许多新选项。用户无需执行任何操作即可访问这些新功能。

如果 TFS/Azure DevOps 无法将任务识别为管道中某项的新版本，则基于 UI 的管道和旧版本管道的用户（以及基本上所有 TFVC 用户）将需要添加该任务的新副本任务，将所有值从 A 复制到 B，然后删除旧任务。我不想让他们那么痛苦。

我猜答案是否定的，但我是否错过了允许我的用户无缝升级的任何选项，但允许我不断改进新用户必须键入 YAML 才能访问这些任务的方式？我不知道有任何方法可以为任务本身（以前的名称、guid）和贡献 ID 提供别名标识......同样，我不知道有一种方法可以让包含重命名的构建任务的扩展在市场上......

Answer 1

我认为您已经回答了自己的问题：

• 保持这种方式。
• 添加新的扩展程序。

是的，对于用户来说，这是一种痛苦。 尤其是当您依赖管理员批准安装扩展程序时。 您可以提供一个 PowerShell 脚本，通过 Azure DevOps 的 REST API 迁移管道中的所有任务。但这仍然需要大量工作，并且需要一定的技术知识（和权限）。

Microsoft 任务是唯一真正简短的任务，但这可能是因为它是本机任务并且没有扩展。 如果您查看市场上的一些扩展名，您并不是唯一一个遇到此“问题”的人。也许微软会想出一个解决方案。