格式化 JavaScript GitHub 工作流 CI

描述我使用 GitHub 工作流和 CI（持续集成）格式化 JavaScript 的过程。我正在尝试新的有效步骤来定义需求和解决方案。我重复这两个，直到找到完整的解决方案。

表中的内容

概括
CI 上的格式代码
定义需求并寻找解决方案
让信息下沉
实施解决方案
关键要点
结果和存储库结构

概括

我想到了在 CI 上格式化代码——持续集成。我写下了要求。我想检查代码是否已格式化。我需要对新代码进行一致的格式检查。 CI 将确保他们运行任何推送代码的人。之后我开始阅读 GitHub 工作流程。四个小时后，我阅读了数十页，寻找符合我要求的描述。我又读了一个小时才让它沉入其中。我在晚上开始实施它，大约花了三十分钟才完成。该设置完美无缺。

CI 上的格式代码

我想格式化关于持续集成的代码。我从经验中知道。我需要定义我想要做什么。在那之后，我可以寻找一种方法来实现它。

定义需求并寻找解决方案

定义需求并寻找解决方案。重复这些步骤，直到问题解决。一个模糊的想法是不够的。下一步是寻找如何设置持续集成。我发现我可以使用 GitHub 工作流目录并定义一组步骤来完成。新的问题是我不知道步骤。我再次重新定义了需求。这一次，我更精确。我想使用持续集成来格式化代码。我想更漂亮地检查代码是否已格式化。这意味着我需要一个包管理器。有了这个，我需要安装包并运行脚本。这一次，我离解决方案更近了。是时候搜索信息了。我开始阅读 GitHub 文档中的工作流程。有很多新术语，但我并不感到不知所措。那是最重要的。第一页提到了工作流程、工作、步骤、操作等。我知道我在寻找什么，所以并不多。我发现作业是并行运行的。但是，作业中的步骤按顺序运行。此外，我可以定义每个工作都可能依赖于以前的工作。我不需要这些信息并继续前进。在处理了几个小时的信息后，我休息了一下。我有信心找到解决方案。但是，我发现了一些问题并想解决它们。我不知道什么是 GitHub 操作。为什么我需要它们？操作是设置作业的一组步骤。我就是这么理解他们的。我必须检查我的存储库并设置 NodeJS 和 Yarn。那一刻，我觉得自己更有信心了。当 CI 失败时，我希望拉取请求失败。我寻找一种方法来做到这一点。我又是对的。默认情况下，持续集成不会这样做。我需要设置一个分支保护规则。我打开了一个分支保护规则进行检查，但没有列出任何内容。我意识到我需要推送一个工作流来将其添加到分支保护中。最后，事实证明我是对的。

让信息下沉

我让信息沉入其中，因为我正忙于其他事情。我不知道那有没有帮助。十二小时后，我有一个相当简单的时间来实施它。我相信我也能马上做到。

实施解决方案

我首先添加了一个检查并确保它失败。我 uglified 一个文件并找到了一个更漂亮的命令来检查文件。后来我用了这个命令，它奏效了。但是，我很怀疑，因为它没有引发错误。更漂亮的文档提到，如果检查发现未格式化的文件，它会返回代码 1。我不知道为什么返回码是相关的。我只是假设返回码意味着失败。毕竟，这就是它的目的。我提交了这些更改并描述了它们的目的。我开始编写 YAML 格式配置。我知道我需要什么，但我不记得语法。我添加了一个名称和工作字段。我为任何分支定义了在每次推送时运行的工作流。我不需要裸操作系统或所谓的跑步者。我添加了一个操作来打开我的存储库并设置节点和纱线。我想我现在可以简单地运行命令。我更改了路径，安装了软件包，然后运行了 format 命令。我推动了分支，但它失败了。事实证明，我没有使用相对路径来更改目录。我解决了这个问题，这一次成功了，持续集成失败了。它失败了，因为文件没有被格式化。我运行了格式化命令并推送了更改。这次持续集成奏效了。是时候验证它是否适用于拉取请求了。不行，我回去配置分支保护规则。这次我的工作流程在清单上。在所有这些步骤之后，持续集成适用于拉取请求和分支。这是一种累人的方法，因为我不习惯这种工作框架。我总是深入研究代码。我总是因此而弄得一团糟。我打开了拉取请求并合并了更改。我很惊讶我花了 5 到 7 个小时才写出 14 行代码。回想起来，每一行代码背后都有很多信息。