我将现有的 GIT 存储库推送到新的 DevOps 存储库，这无意中将消息上带有 #{number} 的所有提交链接到具有该 ID 的工作项。
我已成功识别(通过 REST API 和 CLI)所有工作项以及与提交的关系，但是...
az 板工作项关系删除 --id $workItemID --relation-type 'Artifact Link' --target-id $relationID --org $orgURL --yes失败提示 $relationID 不是有效的工作项，这很奇怪，因为 关系类型 是 Artifact Link 所以我不明白它为什么要尝试获取工作项。使用 REST API 似乎相当危险，因为请求是使用关系的索引完成的；不使用特定 ID 让我感到非常不舒服，我需要验证所有更改，这对于我所接触的票证数量来说实际上是不可能的。
如何通过合理的方法以编程方式删除所有这些关系？最好使用关系的 ID
最佳答案
似乎 Azure Boards cli 扩展假定 targetId 是一个工作项(如父项或子项)并且不支持其他关系)。 docs 中并没有这么说。 ，但关系类型的唯一示例是父级和子级。
--relation-type
Relation type to create. Example: parent, child.
我知道基于索引的寻址并不理想，但为什么使用关系索引在实践中会成为问题？
如果您通过 fetching the workitem 启动脚本并检查该关系具有哪个索引，然后您可以继续使用 workitem update 删除该关系.
我看到这不起作用的唯一原因是，如果有人修改工作项，使得工件链接的索引在 get 和 update 命令之间发生变化(例如删除与较低索引的关系)，这考虑到命令之间的时间很短，这似乎不太可能。在非工作时间或不允许其他事件的约定时间窗口执行脚本可以进一步降低风险。
如果您仍然希望验证更改是否正确执行，您也可以在脚本中自动执行此操作:
- 第一次 Get 后，保存所有关系
- 执行更新(删除与提交的关系)
- 再次获取工作项
- 确保关系中的唯一区别是提交关系已被删除。如果没有，发出警告/退出脚本等。
这是一个类似的问题，可以提供进一步的见解:How to delete a work item relation (parent) from a child task work item via HTTP request to azure devops?
关于azure-devops - 删除 Azure DevOps 工作项之间的关系并以编程方式提交，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/73309758/