不同之处在于,第一个示例作为具有三个命令的单个脚本执行,而第二个示例作为三个不同的单行脚本执行(旁注:第二个示例无效,因为您使用带有name 的步骤而不带run ,我会忽略那行)。
让我们假设npm 在运行时不会产生任何输出。在第一个示例中,如果其中一个命令失败,那么识别哪个命令可能会出现问题 - 您只有一个步骤被标记为失败。在第二个示例中,您将确切地知道问题出在哪里,因为每个命令都有自己的步骤。
让我们假设npm 需要在特定的子目录中运行。我们需要记住,每个步骤总是从工作区目录/repo 的根目录开始,所以我们需要先进入我们的东西所在的目录。
- run: |
cd my/directory
npm ci
npm run build --if-present
npm test
- run: npm ci
working-directory: my/directory
- run: npm run build --if-present
working-directory: my/directory
- run: npm test
working-directory: my/directory
或
- run: cd my/directory && npm ci
- run: cd my/directory && npm run build --if-present
- run: cd my/directory && npm test
让我们假设第二个 npm test 只需要在 push 事件上运行,但工作流配置为运行 on: [push, pull_request]
- run: |
npm ci
npm run build --if-present
if [ "${{ github.event_name }}" == "push" ]; then
npm test
fi
shell: bash
- run: npm ci
- run: npm run build --if-present
- run: npm test
if: github.event_name == 'push'
在Actions选项卡下,处理pull_request事件时,第二个例子会显示为...
- Run npm ci
- Run npm run build...
- Run npm test <-- this one will be grayed out
...您只需要快速查看一下npm test 步骤就被跳过了。在第一个示例中,您必须先扩展步骤并检查日志以发现任何差异。
依此类推,有很多场景使用 all-in-one 步骤更容易/更好,而 command-by-command 步骤是要走的路;由您决定哪一个最适合您。
归根结底,这两个示例都做了完全相同的事情,毕竟。但是,如果在此过程中出现任何问题,选择一种方式运行命令而不是另一种方式(这也会改变它们的显示方式)可能会影响准备修复需要多长时间。