Azure DevOps Pipeline 的代码格式化任务答案

【问题标题】：Code Format Task for Azure DevOps PipelineAzure DevOps Pipeline 的代码格式化任务
【发布时间】：2020-12-01 05:20:25
【问题描述】：

TL;DR - 作为构建过程的一部分，是否有用于格式化代码的 Azure DevOps 管道任务？我一直没能找到它，但我真的觉得它很有用。

我的团队使用免费的CodeMaid Visual Studio 扩展来“美化”（格式化）C# 代码。虽然扩展运行良好，但依赖开发人员在 Visual Studio 中格式化自己的代码存在一些限制：

开发人员经常忘记运行该工具。
启用“保存时自动运行文件清理”可能会令人沮丧，因为它会重新组织代码，这可能会破坏人们的思路。
开发人员可以根据自己的喜好更改格式设置，而不是遵守可能导致代码合并问题和格式冲突的团队的格式标准。

我认为更好的解决方案是在 Azure DevOps 中有一个管道任务，该任务运行像 Code Maid 这样的工具作为构建过程的一部分。这将确保没有代码以丑陋、未格式化的状态进入源代码控制，并确保所有代码都格式化为构建过程中启用的任何标准。

【问题讨论】：

标签： azure-devops azure-pipelines azure-pipelines-build-task

【解决方案1】：

在我看来，触发构建的提交应该是不可变的。如果你把一些东西格式化代码，你将向 repo 推送一个新的提交，以便真正合并更改。那么，您是否要再次触发 CI 构建？

我的建议可能是自动运行格式化工具作为管道的一部分。如果它发现将要进行的任何更改（意味着有人在推送到远程之前没有运行该工具），那么构建失败。使传递构建成为合并拉取请求的要求。如果人们无法通过正常流程完成工作，他们就会排队。您在管道中为其配置的设置将成为标准，以便解决开发人员选择制表符或空格的问题。 :)

Code Maid 可能不是最好的选择。我看到一个开放的 github 票，关于它对于命令行自动化并不是很好。它与 Visual Studio 紧密耦合。此外，这可能需要付出很大的努力，但我想你会希望有人在完整源代码上运行格式化，这样每个人都可以从绿色开始。

【讨论】：

很确定我已经使用 Resharper 完成了这件事。
我越想这个，我就越同意你，马特。即，在构建时更改代码格式将需要一个新的 Git 提交，这很奇怪。如果检测到格式化未运行，则在使管道失败的管道上设置某种“门”将是理想的。我目前使用 CodeMaid 只是因为它是免费的，而且我当前的客户不会为 Resharper 之类的许可证付费。
如果您在让 CodeMaid 在管道或编码单元测试中运行时遇到问题，可以查看 StyleCop。相信它是开源的，并且与 c# 配合得很好。

【解决方案2】：

您可以在命令行上运行本机命令dotnet-format，这将实现您想要的。你可以在你的管道中运行它。它确实需要安装，因此可能会给您的构建增加开销。

使用以下命令安装：

dotnet tool install -g dotnet-format

然后直接在当前格式化当前项目或解决方案，使用：

dotnet format

要修复代码样式分析器警告，您也可以使用此命令：

dotnet format --fix-style warn

可用命令的完整列表位于项目GitHub。

【讨论】：

可以在 Azure DevOps 云服务器上安装自定义工具吗？除了运行任务之外，我认为无法在构建服务器上安装自定义应用程序。
是的，您可以使用管道中的步骤将它们加载到容器中。这是我在管道中使用的工具。 dotnet 命令行实用程序已加载，您只需添加该工具，而不是整个二进制文件。

【解决方案3】：

我认为更好的解决方案是在在构建过程中运行像 Code Maid 这样的工具的 Azure DevOps 过程。这将确保没有代码进入源代码管理丑陋的，未格式化的状态，并确保所有代码都格式化为作为构建的一部分启用的任何标准。

Azure Devops 没有这样的管道任务来在管道运行期间格式化文件。并且不建议在管道运行期间对 git repo 进行更改。

正常情况是：

1.我们在 Azure Devops 中托管了 git repo，有人正在使用 dev 分支进行本地开发。

2.有人做了一些更改并提交更改（修改代码或添加额外的源文件）

3.将提交与远程仓库同步，远程仓库中的更改触发相应的管道运行。（CI 检查代码是否正常，CD 用于部署新更改）

现在如果您在流水线期间修改源文件，除非您禁用 CI，否则将导致无限触发。相反，您可以使用Branch policy 使流程更好，您可以为 master 分支设置分支策略。因此，通过 PR 对 master 所做的任何更改都应得到审阅者的批准。并且特定的审阅者可以帮助检查代码格式。

【讨论】：