在上一篇中，我们探讨了如何使用时间表触发器来自动化任务。在本篇中，我们将深入讨论 GitHub Actions 中作业与步骤的并行和串行执行。这是理解工作流如何高效运行的重要一环。

1. 作业与步骤概述

在 GitHub Actions 中，工作流由多个作业（Job）构成，而作业又由多个步骤（Step）组建。每个作业都是在一个独立的虚拟环境中运行的。步骤则是在作业中定义的一系列命令或操作。

作业和步骤之间的并行与串行运行方式对流水线的效率影响很大。理解这些概念将帮助你更好地设计和优化你的工作流。

2. 串行作业

默认情况下，工作流中的作业是串行执行的。这意味着每个作业必须等前一个完成后才能开始。例如，如果你有两个作业 job1 和 job2，job2 只有在 job1 完成后才会执行。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

name: CI

on: [push]

jobs:
  job1:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Run tests
        run: |
          echo "Running tests for job1"

  job2:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Deploy application
        run: |
          echo "Deploying application from job2"

在上述代码中，job1 和 job2 将顺序执行。job2 只能在 job1 完成后启动。

3. 并行作业

GitHub Actions 允许作业并行运行。要实现这一点，只需确保作业之间没有依赖关系。如果你希望多个作业并行运行，可以在工作流定义中直接定义这些作业。

示例：并行作业

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

name: CI

on: [push]

jobs:
  job1:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Run tests
        run: |
          echo "Running tests for job1"

  job2:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Lint code
        run: |
          echo "Linting code in job2"

  job3:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Build application
        run: |
          echo "Building application in job3"

在这个例子中，job1、job2 和 job3 将并行执行，因为它们之间没有依赖关系。

4. 控制作业的依赖关系

如果你想控制作业的执行顺序，可以使用 needs 关键字来定义依赖关系。这使得某些作业在其他作业完成后才会执行。

示例：控制依赖关系

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

name: CI

on: [push]

jobs:
  job1:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Prepare environment
        run: |
          echo "Preparing environment in job1"

  job2:
    runs-on: ubuntu-latest
    needs: job1  # job2 依赖 job1
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Run tests
        run: |
          echo "Running tests in job2"

  job3:
    runs-on: ubuntu-latest
    needs: job2  # job3 依赖 job2
    steps:
      - name: Deploy application
        run: |
          echo "Deploying in job3"

在这个示例中，job2 在 job1 完成后执行，而 job3 则在 job2 完成后执行。这里使用 needs 关键字创建了依赖链，使得作业按顺序执行。

5. 总结

在本篇中，我们讨论了 GitHub Actions 中作业的并行与串行执行，展示了如何通过定义依赖关系来控制作业的执行顺序。从业务场景出发合理设计工作流，能够有效提升 CI/CD 的效率和稳定性。

在下一篇中，我们将探讨作业与步骤之间的依赖关系，进一步提升你对 GitHub Actions 的理解和应用。希望你能在实际项目中灵活运用这些知识，优化你的工作流！

在上一篇中，我们探讨了在 GitHub Actions 中如何实现作业之间的并行与串行执行。本篇将继续深入探讨作业与步骤之间的依赖关系，帮助您更好地控制工作流的执行顺序。

什么是依赖关系？

在 GitHub Actions 中，依赖关系是指某个作业或步骤的执行必须依赖于先前作业或步骤的结果。通过定义这些依赖关系，我们可以确保某些操作在其他操作完成后才执行，从而避免潜在的错误和不一致。

例如，您可能希望在构建应用程序之前，先运行测试用例。这可以通过在工作流配置文件中设置依赖关系来实现。

步骤的依赖关系

GitHub Actions 中的步骤（steps）是作业（jobs）中的基本单元。每个作业都可以由多个步骤构成，而步骤之间的依赖关系是通过执行顺序来管理的。默认情况下，步骤是按顺序依次执行的，但我们也可以通过条件语句来控制某些步骤的执行。

示例：简单的步骤依赖关系

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

name: CI

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Check out code
        uses: actions/checkout@v2

      - name: Set up Node.js
        uses: actions/setup-node@v2
        with:
          node-version: '14'

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test

      - name: Build application
        run: npm run build

在上述示例中，步骤 Run tests 依赖于 Install dependencies 步骤，这表明我们必须先安装依赖后才能运行测试。依赖关系通过执行的顺序来隐含定义。

使用条件控制步骤的执行

为了更精细地控制步骤的执行，我们可以使用 if 语句来设定条件。例如，假设我们希望仅在测试通过时才执行构建步骤，可以加入条件判断。

1
2
3
4
5
6
7

- name: Run tests
  run: npm test
  id: test_step

- name: Build application
  run: npm run build
  if: steps.test_step.outcome == 'success'

在此示例中，Build application 步骤依赖于 Run tests 的执行结果，仅在测试成功时才会被执行。

作业之间的依赖关系

除了步骤之间的依赖关系，作业之间的依赖关系同样重要。为了使得一个作业在另一个作业完成后才开始执行，可以使用 needs 关键字。

示例：作业依赖关系

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

name: CI

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Check out code
        uses: actions/checkout@v2
      
      - name: Set up Node.js
        uses: actions/setup-node@v2
        with:
          node-version: '14'

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test

  build:
    runs-on: ubuntu-latest
    needs: test
    steps:
      - name: Check out code
        uses: actions/checkout@v2

      - name: Build application
        run: npm run build

在这个例子中，build 作业依赖于 test 作业的完成（通过 needs: test 来建立依赖关系）。这样可以确保在测试完成后，才开始执行构建作业。

结论

本篇文章详细探讨了 GitHub Actions 中作业与步骤之间的依赖关系。通过合理设置步骤的执行顺序和作业之间的依赖，您可以确保工作流的顺利和精确执行。在下一篇中，我们将讨论如何设定作业的条件执行，这将进一步提升您的工作流的灵活性与控制力。

继续关注系列教程，深入了解 GitHub Actions 的强大功能！

在上一课中，我们探讨了作业与步骤之间的依赖关系，了解了如何通过依赖链来控制工作流的执行顺序。本篇将继续深入探讨 GitHub Actions 中的条件执行，帮助你掌握如何根据特定条件来决定某个作业或步骤是否执行。

什么是条件执行？

条件执行允许我们根据特定条件来决定是否执行某个作业或步骤。你可以使用 if 语句来定义条件，可以根据环境变量、作业结果或任何布尔表达式来实现。

基本语法

在 GitHub Actions 中，条件执行通常与工作流的作业或步骤结合使用。条件使用 if 关键字定义，格式如下：

1

if: <条件表达式>

条件语法示例

示例一：根据作业结果执行步骤

假设我们有一个 CI 流程，其中一个作业是测试（test），另一个作业是部署（deploy）。我们希望仅在测试通过时才执行部署。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

name: CI Workflow

on: [push]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Run tests
        run: |
          echo "Running tests..."
          exit 0  # 假设测试通过

  deploy:
    runs-on: ubuntu-latest
    needs: test
    if: success()  # 仅在测试成功时执行
    steps:
      - name: Deploy to production
        run: echo "Deploying to production..."

在这个示例中，deploy 作业的执行条件是 test 作业成功完成。你可以通过 success() 函数来定义这种条件。

示例二：根据环境变量执行步骤

条件执行不仅限于作业间的依赖关系，还可以基于环境变量，允许你更灵活地控制工作流。假设我们有一个环境变量 RUN_DEPLOY，它决定了是否进行部署。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

name: Conditional Deployment Workflow

on: [push]

env:
  RUN_DEPLOY: ${{ secrets.RUN_DEPLOY }}

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Run tests
        run: |
          echo "Running tests..."
          exit 0  # 假设测试通过

  deploy:
    runs-on: ubuntu-latest
    needs: test
    if: env.RUN_DEPLOY == 'true'  # 基于环境变量决定是否执行
    steps:
      - name: Deploy to staging
        run: echo "Deploying to staging..."

在这个示例中，deploy 作业仅在环境变量 RUN_DEPLOY 的值为 'true' 时执行。这使得你可以控制部署过程而不必修改工作流的逻辑。

组合条件

你还可以使用复合条件来增强条件判断的灵活性。例如，你可以将作业的成功状态与环境变量结合。

1

if: success() && env.RUN_DEPLOY == 'true'  # 同时检查作业成功与环境变量

小结

在本篇中，我们深入探讨了 GitHub Actions 中的条件执行，学习了如何根据作业结果和环境变量动态控制作业或步骤的执行。通过这些条件控制，你能够构建更复杂且灵活的 CI/CD 流程，确保工作流在合适的条件下执行。

在下一篇教程中，我们将讨论环境变量与秘密变量的使用，深入了解如何安全且高效地管理敏感数据。希望你能持续关注，掌握更多 GitHub Actions 的技巧！

在前一篇文章中，我们探讨了作业与步骤的条件执行，以及如何根据条件来控制工作流的执行。现在，让我们深入了解环境变量的使用，特别是如何在 GitHub Actions 中生成和使用环境变量，以及如何处理包含敏感数据的秘密变量。

1. 环境变量的概念

环境变量是一些存储在操作系统环境中的动态值，可以在应用程序运行时被读取。在 GitHub Actions 中，环境变量可以帮助我们传递配置和信息，增强工作流的灵活性。’’’关键’’’环境变量通常用于传递路径、版本或其他重要信息，可以在不同的作业和步骤之间共享。

2. 创建和使用环境变量

2.1 在工作流中定义环境变量

在 GitHub Actions 工作流中，可以在 jobs 或 steps 中通过 env 关键字定义环境变量。环境变量的作用范围依赖于它们被定义的级别。

以下是如何在作业级别和步骤级别定义环境变量的示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

name: Example Workflow

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      GLOBAL_VAR: 'Hello, World' # 在该作业中定义环境变量
    steps:
      - name: Print Global Variable
        run: echo $GLOBAL_VAR

      - name: Set Step Variable
        run: |
          echo "LOCAL_VAR=This is a step-specific variable" >> $GITHUB_ENV
          echo "LOCAL_VAR is set to $LOCAL_VAR"

在上面的示例中：

• GLOBAL_VAR 是在作业级别定义的环境变量，可以在该作业的所有步骤中使用。
• LOCAL_VAR 是通过将其输送到特殊的 $GITHUB_ENV 文件中创建的步骤级别环境变量，它仅在当前步骤后续的步骤中有效。

2.2 传递环境变量到步骤

若需要在不同的步骤间传递变量，可以使用 run 命令或者 with 参数。以下是一个示例：

1
2
3
4
5
6

- name: Set Local Variable
  run: |
    echo "MY_VAR=This is a variable" >> $GITHUB_ENV

- name: Use Local Variable
  run: echo "The variable is $MY_VAR"

在这个例子中，MY_VAR 在第一个步骤中被设置，并在第二个步骤中打印。

3. 使用秘密环境变量

GitHub Secrets 提供了一种安全的方式来存储敏感信息，如 API 密钥或密码。为确保安全，秘密变量在运行时会被提供给工作流，但在日志中不会被打印。

3.1 添加和使用秘密变量

在 GitHub 上，您可以通过仓库的设置页面添加秘密变量。添加后，您可以在工作流中使用它们，如下所示：

1
2
3
4
5
6
7
8
9
10
11

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Use Secret
        env:
          SECRET_API_KEY: ${{ secrets.SECRET_API_KEY }} # 访问秘密变量
        run: echo "Using API Key $SECRET_API_KEY"

在上面的代码中，SECRET_API_KEY 是我们在 GitHub 设置中添加的秘密变量。在工作流中，我们通过 ${{ secrets.SECRET_API_KEY }} 访问它。

4. 注意事项

• 变量作用范围：请注意环境变量的作用范围，确保在合适的级别定义它们。
• 安全性：切勿将秘密变量打印到日志中，避免泄漏敏感信息。
• 使用 JSON 格式：如果需要传递多个环境变量，可以考虑使用 JSON 格式并将其解析。

1
2
3
4
5
6
7
8

- name: Set Multiple Variables
  run: |
    echo 'ENV_VARS="{\"var1\":\"value1\",\"var2\":\"value2\"}"' >> $GITHUB_ENV

- name: Use Multiple Variables
  run: |
    VAR1=$(echo $ENV_VARS | jq -r '.var1')
    echo $VAR1

5. 小结

在本篇文章中，我们利用示例详细介绍了环境变量和秘密变量的使用。环境变量帮助我们在 GitHub Actions 工作流中灵活传递信息，而秘密变量则保障了我们敏感配置的安全。在下一篇文章中，我们将讨论环境变量与秘密的管理，包括如何有效地维护和使用这些变量。希望本篇的内容能帮助你更好地构建你的 CI/CD 流程！

在上一篇文章中，我们探讨了如何在 GitHub Actions 中使用环境变量来提高工作流程的灵活性和可维护性。这一篇将重点关注如何有效管理和保护秘密，确保它们的安全，并合理地使用它们。

什么是秘密？

在 GitHub Actions 中，秘密（secrets）用于存储敏感信息，如 API 密钥、数据库密码或任何其他不应公开的信息。这些秘密在工作流程运行时可以作为环境变量使用，但它们不会出现在构建日志中，因此可以有效防止敏感信息泄露。

如何管理秘密？

1. 添加秘密

在你的 GitHub 仓库中添加秘密非常简单：

1. 进入你的仓库，点击 Settings（设置）。
2. 找到 Secrets部分，选择 Actions。
3. 点击 New repository secret（新建仓库秘密）。
4. 输入一个名称，这将是你在工作流程中引用的标识符，例如 API_KEY。
5. 输入秘密的值并保存。

2. 在工作流程中使用秘密

一旦你添加了秘密，就可以通过 secrets 关键字在工作流程中使用它们。以下是一个示例 workflow.yml 文件，展示了如何使用秘密：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

name: CI

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Set up Node.js
        uses: actions/setup-node@v2
        with:
          node-version: '14'

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test

      - name: Deploy
        env:
          API_KEY: ${{ secrets.API_KEY }}
        run: |
          echo "Deploying with API key..."
          curl -H "Authorization: Bearer $API_KEY" https://api.example.com/deploy

在这个示例中，API_KEY 被从 GitHub Secrets 中提取，并传递给了 curl 命令。通过这种方式，API_KEY 的值不会出现在构建日志中，确保了它的安全性。

密码的安全性管理

1. 只授予必要的权限

在添加秘密时，除了存储敏感信息之外，确保这些信息只被需要的工作流程访问。避免将秘密暴露给所有成员或所有工作流程，以降低潜在风险。

2. 定期更新秘密

为了保持代码库的安全性，建议定期更新秘密的值。例如，API 密钥的使用期限可能不应过长。你可以设置提醒，定期检查并更新秘密内容。

3. 使用环境特定的秘密

对于不同的环境（如开发、测试、生产），建议使用不同的秘密。例如，可以在生产环境中使用不同的数据库密码和 API 密钥。通过这种方式，可以有效降低在环境间切换时带来的风险。

1
2
3
4
5
6
7
8
9

jobs:
  deploy_to_production:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to production
        env:
          PROD_API_KEY: ${{ secrets.PROD_API_KEY }}
        run: |
          curl -H "Authorization: Bearer $PROD_API_KEY" https://api.example.com/deploy

在上面的示例中，我们在生产工作流中使用了专门为生产环境配置的 PROD_API_KEY 秘密。

小结

在本篇中，我们深入探讨了如何管理和使用秘密，以提高 GitHub Actions 工作流程的安全性。通过合理管理秘密，确保只有授权人员和工作流程可以访问敏感信息，可以大大降低潜在的安全风险。在下一篇文章中，我们将讨论环境变量与秘密的安全性最佳实践，进一步增强开发流程中的安全性。

请密切关注我们的系列教程，以便更深入了解 GitHub Actions 的其他功能和最佳实践。

在上一篇中，我们深入探讨了环境变量与秘密的管理机制，以及如何在 GitHub Actions 中安全地存储和使用这些敏感信息。这一篇将围绕安全性最佳实践展开，帮助你在使用环境变量和秘密时最大限度降低安全风险。

理解安全性的重要性

在软件开发中，尤其是在 CI/CD 流程中，保持环境变量和秘密的安全性至关重要。泄露的 API 密钥、数据库密码或其他敏感信息可能导致数据泄露或服务中断。因此，我们需要采取一系列措施确保这些信息的安全性。

安全性最佳实践

1. 使用 GitHub Secrets 存储敏感信息

GitHub 提供了 Secrets 功能，专门用于安全存储敏感信息。在你的 GitHub 仓库中，你可以按照以下步骤添加秘密：

1. 在你的仓库页面中，点击“Settings”。
2. 在左侧菜单中选择“Secrets and variables”。
3. 再选择“Actions”。
4. 点击“New repository secret”来添加新的秘密。

一旦添加，你可以在 Actions 工作流程中安全地引用这些秘密。例如，假设你有一个名为 MY_SECRET 的秘密，可以在工作流程中使用：

1
2
3

steps:
  - name: Use a secret
    run: echo "${{ secrets.MY_SECRET }}"

注意： 确保不要直接在日志中打印秘密，这可能会导致信息泄露。

2. 限制访问权限

在设置秘密时，确保只对需要使用这些秘密的人员和工作流程授予访问权限。GitHub 允许你为团队成员设置不同的访问级别，确保只有授权人员能够访问这些敏感信息。

此外，考虑使用 Environment 来部署只在特定工作流程中需要的秘密。将秘密绑定到特定环境中，有助于减少潜在的安全风险。

3. 避免在代码中硬编码敏感信息

尽量避免在代码中直接硬编码敏感信息。这不仅会增加敏感信息被泄露的风险，也会使得代码难以维护。

例如，下面的示例展示了一个不安全的做法：

1

const apiKey = 'sk_test_4eC39HqLyjWDarjtT1zdp7dc'; // 不推荐

相反，使用环境变量或秘密来存储这些信息：

1

const apiKey = process.env.API_KEY; // 推荐

4. 定期审查与轮换秘密

为了提高安全性，应定期审查和轮换秘密。即使秘密在某个时刻是安全的，也不能保证它会一直安全。因此，定期更新秘密是一种有效的实践。

你可以通过 GitHub 的 API 或 CLI 工具自动化此过程。例如，使用 GitHub CLI 更新秘密：

1

gh secret set MY_SECRET -b"new_secret_value"

5. 监控和审计使用情况

定期监控和审计秘密的使用情况是维护安全性的重要环节。确保设置合适的监控机制，并检查是否有任何异常的访问或使用活动。

GitHub 提供了丰富的审计日志功能，帮助你追踪对秘密的访问和使用情况。在设置秘密后，定期检查审计日志，可以帮助你发现潜在的安全隐患。

6. 参考文档与社区资源

GitHub 官方文档提供了详尽的信息，确保你熟悉所有最佳实践，并遵循安全性指导方针。参考链接如下：

• GitHub Actions: Managing Secrets
• GitHub: Best Practices for Securing Secrets

小结

安全使用环境变量和秘密是确保 GitHub Actions 工作流程安全的关键。通过运用上述最佳实践，能有效降低信息泄露的风险。

在下一篇中，我们将深入探讨如何使用市场行动（Marketplace Actions）来扩展 GitHub Actions 的功能。希望这些安全性最佳实践能够在你自动化工作流的过程中提供帮助，一同守护你的项目安全！

在上一篇中，我们探讨了环境变量和秘密的安全性最佳实践，学习如何保证我们的 GitHub Actions 工作流程在使用敏感信息时保持安全。现在，接下来我们将聚焦于如何在 GitHub Actions 中使用市场行动（Marketplace Actions）。市场行动提供了许多现成的解决方案，可以帮助我们自动化各种任务，节省开发时间和精力。

什么是市场行动？

市场行动是 GitHub 提供的一种机制，允许开发人员创建和共享可以在 GitHub Actions 工作流程中使用的可重用组件。这些市场行动可以处理许多不同的任务，比如部署代码、执行测试、发送通知等。

为什么使用市场行动？

使用市场行动的优势包括：

• 节省时间：通过使用已有的行动，我们可以避免重复造轮子，快速集成社区提供的功能。
• 降低复杂性：市场行动通常经过测试并且由社区维护，使用它们能够减少我们在自动化过程中遇到的复杂性。
• 可重用性：一旦我们熟悉某个市场行动，它可以在不同的项目和工作流程中被重复使用。

如何使用市场行动

1. 查找市场行动

首先，我们需要找到适合我们需求的市场行动。GitHub 提供了一个方便的界面，可以在GitHub Marketplace上浏览和搜索行动。

示例搜索

假设我们希望找到用于部署到 AWS 的市场行动。我们可以在 Marketplace 中使用关键词 AWS 进行搜索，查找与 AWS 集成的相关行动。

2. 使用市场行动

一旦找到我们想要的市场行动，就可以在我们的工作流程中使用它。为了说明这一点，我们将创建一个简单的工作流程，使用市场行动来使用 actions/checkout 操作和 tschaub/gh-pages 操作将我们的代码部署到 GitHub Pages。

以下是一个示例工作流程：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

name: Deploy to GitHub Pages

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
        
      - name: Deploy to GitHub Pages
        uses: tschaub/gh-pages@v3
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./public

在上面的工作流程中：

• 我们监控 main 分支的 push 事件。
• 第一步骤使用 actions/checkout@v2 操作克隆代码库，以便工作流可以访问我们的代码。
• 第二个步骤使用 tschaub/gh-pages@v3 操作，将构建目录 ./public 的内容部署到 GitHub Pages。

3. 传递输入和配置

许多市场行动支持传递输入参数。当我们使用某个市场行动时，通常可以在使用时传入必要的配置。

例如，在前面的示例中，我们传入了 github_token 和 publish_dir，这些值是根据我们需要的配置指定的。要了解这个市场行动支持哪些输入参数，我们可以查看它对应的文档。

结语

市场行动是 GitHub Actions 的强大工具，使我们能够轻松实现复杂的自动化任务。在使用市场行动时，确保为每个步骤提供必要的输入，并参考官方文档以获取最佳实践和配置选项。

在下一篇文章中，我们将讨论如何查找和选择适合我们需求的市场行动，确保我们能够充分利用这一资源，以增强我们的自动化流程。通过深入了解这些行动，我们将能够更好地在工作流程中实现高效和稳定的自动化操作。

在上一篇中，我们探讨了什么是市场行动以及如何在你的工作流中使用它们。现在，我们将深入了解如何在 GitHub Actions 市场中查找和选择适合你项目的行动。使用正确的行动可以大大提高你的工作流效率，简化开发过程，并减少重复性工作。

1. 理解 GitHub Actions 市场

GitHub Actions 市场是一个集成了大量现成的行动的库。你可以在这里找到各种用途的行动，如 CI（持续集成）、CD（持续交付）、自动化测试等。市场中的行动由社区和开发者创建，并且可以被其他用户引用和使用。

1.1 访问市场

要访问 GitHub Actions 市场，你可以访问GitHub Marketplace。在这里，你会看到各种按类别分类的行动。

2. 如何查找行动

2.1 使用搜索功能

市场提供了一个强大的搜索功能，你可以通过关键字、类别、标签等来快速找到所需的行动。例如，如果你需要一个用于运行 Node.js 测试的行动，你可以输入 “Node.js test”。

1

在 GitHub Actions 市场的搜索框中输入 `Node.js test`，你会发现许多相关的行动。

2.2 按类别浏览

你还可以通过点击不同的类别，例如 CI/CD、测试、部署 等来浏览相关的行动。分类浏览可以帮助你发现一些你可能不知道也需要的行动。

3. 选择合适的行动

找到想要的行动后，接下来是选择合适的行动。选择一个合适的行动通常需要考虑以下几点：

3.1 行动的维护情况

查看行动的维护情况是非常重要的。检查以下几个指标：

• 最近更新：一个最近更新过的行动通常意味着它在不断维护和改进。
• 使用人数：被多人使用和评价的行动，通常更可靠。
• 贡献者：作者的可靠性也是一个重要因素，通常选择那些由知名组织或可信的社区成员维护的行动能更让人放心。

3.2 评估文档和示例

良好的文档是行动成功的一大关键。在每个行动的页面上，你应该找到：

• 使用说明
• 配置选项
• 常见问题解答

1
2
3
4
5
6

例如，对于名为 `actions/setup-node` 的行动，你可以在其页面上找到关于如何安装 Node.js 的详细说明：
```yaml
- name: Set up Node.js
  uses: actions/setup-node@v2
  with:
    node-version: '14'

3.3 评估功能和配置

确保选中的行动能够满足你的需求。例如，某些行动可能支持特定的环境变量或特定的参数设置。对比多个行动，以确保选中的行动可以实现你的目标。

4. 实际案例：选择一个测试行动

假设你正在构建一个使用 Node.js 的 Web 应用，并需要设置测试环境。你在市场中搜索到几个选项，包括：

• actions/setup-node
• npm/test
• actions/jest

4.1 确定要求

你需要的是一个能够安装 Node.js 和运行 Jest 测试的行动。

4.2 选择适合的行动

• actions/setup-node 可以安装 Node.js 版本。
• actions/jest 似乎完美匹配你的需求，因为它是一个专门为运行 Jest 测试而设计的行动。

4.3 使用选定的行动

你可以在工作流文件中这样使用选中的行动：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

name: Node.js CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Set up Node.js
      uses: actions/setup-node@v2
      with:
        node-version: '14'
    - name: Install dependencies
      run: npm install
    - name: Run tests
      uses: actions/jest@v1

5. 小结

在 GitHub Actions 市场中，查找和选择行动是一个重要的步骤。通过搜索和浏览，你可以找到适合你项目的现成行动，并确保它们的文档、维护状态和功能满足你的需求。在下一篇中，我们将讨论如何引入第三方行动，为你的工作流增添更多的功能和灵活性。希望这篇文章能帮助你更好地利用 GitHub Actions 市场，提升你的开发效率！

在上一篇中，我们探讨了如何有效地查找和选择适合自己项目的 GitHub 行动。现在，我们将进一步了解如何在我们的工作流中引入这些市场上的第三方行动。通过使用这些行动，我们可以大大简化工作流程，节省时间并减少重复的工作。

1. 什么是第三方行动？

第三方行动是指在 GitHub Marketplace 上发布的预构建的操作。这些行动是由其他开发者或团队创建的，可以帮助我们在 CI/CD 流程中执行特定的任务，比如测试、构建、部署等。使用这些行动时，我们只需通过简单的配置即可让我们的工作流具备更多能力。

2. 如何引入第三方行动？

2.1 查找适合的行动

引入第三方行动的第一步是查找合适的行动。你可以在 GitHub Marketplace 上浏览、搜索不同的行动。在选择时，请关注以下几点：

• 评分和使用情况：选择有较高评分和活跃使用的行动。
• 文档：查看每个行动是否有详细的文档，说明如何配置和使用它。
• 更新频率：选择最近有更新的行动，保证其兼容性和安全性。

2.2 引入行动的格式

在你的工作流文件 (.github/workflows/your-workflow-file.yml) 中引入第三方行动的基本格式如下：

1
2
3

steps:
  - name: 使用示例行动
    uses: owner/repo@version

其中 owner/repo 是 GitHub 仓库的所有者和名称，version 是特定版本或者标签（如 v1.0.0），也可以使用 branch（如 main）或者 latest。

2.3 示例：使用 actions/checkout

作为一个简单的例子，假设我们想要在工作流中引入 actions/checkout 行动，以自动检出代码。以下是完整的工作流配置示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

name: 示例工作流

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: 检出代码
        uses: actions/checkout@v2

      - name: 设置 Node.js 版本
        uses: actions/setup-node@v2
        with:
          node-version: '14'

      - name: 安装依赖
        run: npm install

      - name: 运行测试
        run: npm test

在上面的示例中，我们首先引入了 actions/checkout 来拉取项目代码，这是一个在 CI/CD 流程中经常使用的行动。接着我们设置 Node.js 环境、安装依赖并运行测试。

2.4 引入多个第三方行动

在一个工作流中，你可以引入多个第三方行动。以下是一个更复杂的示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

name: CI 工作流

on:
  push:
    branches:
      - main

jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - name: 检出代码
        uses: actions/checkout@v2

      - name: 设置 Python 版本
        uses: actions/setup-python@v2
        with:
          python-version: '3.8'

      - name: 安装依赖
        run: pip install -r requirements.txt

      - name: 运行单元测试
        run: pytest

      - name: 构建 Docker 镜像
        uses: melvin0008/docker-build@v1
        with:
          context: .
          file: Dockerfile

在这个示例中，我们引入了 actions/setup-python 行动来设置 Python 版本，并引入了 melvin0008/docker-build 行动来构建 Docker 镜像。这样的配置能使工作流更加灵活和强大。

3. 注意事项

• 版本管理：尽量指定具体的版本而非使用 latest，以避免潜在的不兼容或错误。
• 测试：在引入新的行动后，确保充分测试工作流，以验证其是否正常运行。

4. 小结

通过引入市场上的第三方行动，我们可以方便地扩展 GitHub Actions 的功能，减少了手动编写代码的需求。在确定合适的行动后，只需简单的配置，就能实现更多的自动化操作。接下来，我们将讨论如何创建并使用自定义行动，以满足更特定的需求。

希望这篇教程能够帮助你更好地理解如何引入第三方行动，并将其应用于你的项目中！

在上一篇中，我们探讨了如何使用 GitHub Actions 市场上的第三方行动来提升我们的工作流程。今天，我们将深入学习如何创建自己的自定义行动，以便于满足特定的需求或实现个性化的功能。

自定义行动为开发者提供了更高的灵活性和控制力。你可以根据项目的需要，编写专属于你的行动，甚至可以封装复杂的逻辑以便重用。

自定义行动的基本概念

自定义行动可以是一个简单的 JavaScript 文件、一个 Docker 容器，或者一个组合了多个步骤的 YAML 文件。我们将在这篇文章中聚焦于如何利用 JavaScript 来创建自定义行动，并为后续使用 Docker 容器的文章做铺垫。

创建自定义行动的步骤

1. 设置项目结构

首先，创建一个新的 GitHub 仓库，假设我们把这个仓库命名为 my-custom-action。然后在项目根目录下创建以下结构：

1
2
3
4
5

my-custom-action/
│
├── action.yaml
├── index.js
└── package.json

• action.yaml 是自定义行动的元数据文件。
• index.js 是执行逻辑的 JavaScript 文件。
• package.json 用于管理项目依赖。

2. 编写 action.yaml

在 action.yaml 文件中定义自定义行动的元数据：

1
2
3
4
5
6
7
8
9
10

name: 'My Custom Action'
description: 'A simple custom action that greets by name'
inputs:
  name:
    description: 'Name to greet'
    required: true
    default: 'World'
runs:
  using: 'node12'
  main: 'index.js'

上面的代码定义了一个名为 “My Custom Action” 的自定义行动，它接受一个名为 name 的输入参数，并在 JavaScript 文件中执行操作。

3. 编写 index.js

在 index.js 中编写实际执行的逻辑：

1
2
3
4
5
6
7
8
9
10
11
12
13

const core = require('@actions/core');

async function run() {
  try {
    const name = core.getInput('name');
    console.log(`Hello ${name}!`);
    core.setOutput('greeting', `Hello ${name}!`);
  } catch (error) {
    core.setFailed(error.message);
  }
}

run();

在这里，我们使用 @actions/core 包来获取输入参数，并输出一条问候消息。如果发生错误，将会调用 core.setFailed 来标记行动为失败。

4. 配置 package.json

在 package.json 中定义项目的基本信息和依赖项：

1
2
3
4
5
6
7
8

{
  "name": "my-custom-action",
  "version": "1.0.0",
  "main": "index.js",
  "dependencies": {
    "@actions/core": "^1.5.0"
  }
}

确保你的自定义行动使用到的依赖（如 @actions/core）已经在 package.json 中进行配置。

5. 使用自定义行动

现在，你可以在 .github/workflows 目录下创建一个工作流文件（例如 run-custom-action.yml），并使用我们刚才创建的自定义行动：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

name: Custom Action Workflow

on: [push]

jobs:
  greet:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      
      - name: Run My Custom Action
        uses: ./  # 使用当前目录的自定义行动
        with:
          name: 'GitHub User'

当代码被推送到仓库时，上述工作流将会触发，并调用你的自定义行动，以便输出问候消息。

总结

在这一节中，我们详细探讨了如何创建一个简单的自定义行动。我们通过代码逐步构建了从元数据文件到执行逻辑的完整流程。自定义行动的灵活性使得它们能够被重复使用和扩展，为不同的项目带来便利。

在下一篇中，我们将更进一步，探讨如何使用 Docker 容器创建自定义行动，为复杂的工作流程提供更加稳健的支持。

在本篇教程中，我们将探索如何使用 Docker 容器创建自定义 GitHub Actions。这是自定义行动系列教程中的一部分，紧接着上一篇有关创建自定义行动的内容，并为下一篇关于编写 JavaScript 行动打下基础。

什么是 Docker 容器？

在深入主题之前，让我们先简要了解一下 Docker 容器。Docker 是一个开放源码的平台，它可以让开发者打包、分发和管理应用程序。Docker 容器是轻量级、可移动且自给自足的软件包，里面包含了程序运行所需的所有代码、库和依赖项，确保在任何环境中都能保持一致的运行效果。

创建自定义行动

我们将创建一个简单的自定义行动，使用 Docker 容器执行一段代码。在本例中，我们将创建一个算术操作的行动，该行动会接收两个数字并输出它们的和。

第一步：准备项目

在 GitHub 存储库中创建以下文件结构：

1
2
3
4

my-custom-action/
  ├── Dockerfile
  ├── action.yml
  └── entrypoint.sh

第二步：编写 Dockerfile

在 Dockerfile 中，我们需要定义如何构建 Docker 镜像。以下是一个简单的示例：

1
2
3
4
5
6
7
8
9
10
11

# 使用官方的 Node.js 镜像
FROM node:14

# 创建并设置工作目录
WORKDIR /usr/src/app

# 复制 entrypoint.sh
COPY entrypoint.sh .

# 设置 entrypoint
ENTRYPOINT ["bash", "./entrypoint.sh"]

第三步：编写 entrypoint.sh

entrypoint.sh 是我们自定义行动的核心，它将处理输入并执行逻辑：

1
2
3
4
5
6
7
8
9
10
11

#!/bin/bash

# 读取输入参数
num1=$1
num2=$2

# 计算和
sum=$((num1 + num2))

# 输出结果
echo "The sum of $num1 and $num2 is: $sum"

确保脚本是可执行的，您可以运行以下命令：

1

chmod +x entrypoint.sh

第四步：编写 action.yml

接下来，我们需要定义该行动的元数据。在 action.yml 文件中，您可以描述自定义行动的输入、输出和其他配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

name: "Add Numbers"
description: "A GitHub Action that adds two numbers."
inputs:
  num1:
    description: "The first number."
    required: true
  num2:
    description: "The second number."
    required: true
outputs:
  sum:
    description: "The sum of the two numbers."
runs:
  using: "docker"
  image: "Dockerfile"

第五步：测试自定义行动

现在，我们已经创建了自定义行动，可以在工作流中进行测试。创建一个名为 .github/workflows/test.yml 的工作流文件，内容如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

name: Test Add Numbers

on:
  push:
    branches:
      - main

jobs:
  add-numbers:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      
      - name: Add two numbers
        uses: ./my-custom-action
        with:
          num1: 10
          num2: 20

第六步：提交并观察结果

将所有更改提交到 GitHub：

1
2
3

git add .
git commit -m "Add custom action using Docker"
git push

在 GitHub Actions 界面中，您可以看到工作流的执行结果，输出将显示两个数字的和。

结论

在本篇教程中，我们介绍了如何使用 Docker 容器创建自定义 GitHub Actions。通过实例和代码，我们演示了如何构建、定义和测试一个简单的自定义行动。实践这些步骤后，您可以根据需求扩展功能或集成更复杂的逻辑。

在下一篇中，我们将探讨如何编写 JavaScript 行动，这是另一种创建自定义行动的方式，提供了更多灵活性和可移植性。敬请期待！

在前一篇文章中，我们讨论了如何使用 Docker 容器创建自定义 GitHub Actions。这一次，我们将深入探讨如何编写基于 JavaScript 的自定义行动。在实际开发中，JavaScript 行动因其简单性和灵活性而广受欢迎。

为什么选择 JavaScript 行动？

JavaScript 行动的优点包括：

• 易于调试：因为可以在 Node.js 环境中运行。
• 跨平台兼容性：JavaScript 脚本可以在不同操作系统上运行，无需考虑容器化的复杂性。
• 使用丰富的库：可以利用 npm 生态系统中众多的库来拓展功能。

编写基础的 JavaScript 行动

步骤 1：创建行动目录

首先，创建一个新的目录用于存放你的行动代码：

1
2

mkdir my-javascript-action
cd my-javascript-action

步骤 2：初始化项目

使用 npm 初始化项目：

1

npm init -y

这将生成一个 package.json 文件，方便管理依赖和配置。

步骤 3：安装 GitHub Actions 工具

接下来，安装 @actions/core 和 @actions/github 这两个库，它们提供了与 GitHub Actions API 交互的工具：

1

npm install @actions/core @actions/github

步骤 4：编写 JavaScript 行动脚本

在项目根目录下，创建一个 index.js 文件，并加入以下代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

const core = require('@actions/core');
const github = require('@actions/github');

try {
  // 获取输入参数
  const name = core.getInput('name') || 'World';
  
  // 输出到日志
  const time = new Date().toTimeString();
  core.info(`Hello ${name}! The current time is ${time}.`);

  // 获取当前提交信息
  const context = github.context;
  core.info(`Current ref: ${context.ref}`);
} catch (error) {
  core.setFailed(error.message);
}

步骤 5：创建 action.yml 文件

在项目目录下，创建一个名为 action.yml 的文件，该文件配置了你的 GitHub Action：

1
2
3
4
5
6
7
8
9
10

name: 'My JavaScript Action'
description: 'A simple JavaScript action that greets you'
inputs:
  name:
    description: 'Who to greet'
    required: false
    default: 'World'
runs:
  using: 'node12'
  main: 'index.js'

这个文件定义了自定义行动的基本信息，包括输入参数和执行的主程序。

步骤 6：创建工作流

现在，我们需要创建一个工作流来使用这个自定义行动。在你的 GitHub 仓库中，创建一个 .github/workflows 目录，并在其中创建一个名为 main.yml 的文件，内容如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

name: My CI

on:
  push:
    branches:
      - main

jobs:
  greet:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      
      - name: Greet user
        uses: ./  # 使用当前目录中的自定义行动
        with:
          name: 'GitHub User'

在这个工作流中，我们定义了一个名为 greet 的作业，它会在每次推送到 main 分支时运行，调用我们刚刚创建的 JavaScript 行动。

步骤 7：测试行动

将更改推送到你的 GitHub 仓库，观察 Actions 标签页，确认你的工作流是否成功触发并运行。当动作执行时，你应该能够看到类似如下的输出：

1
2

Hello GitHub User! The current time is 14:00:00 GMT+0000 (Coordinated Universal Time).
Current ref: refs/heads/main

结语

通过上述步骤，我们成功编写了一个简单的 JavaScript 行动，并将其集成到 GitHub Actions 工作流中。这样，你便可以根据需要灵活地扩展这个行动，加入更多功能或复杂的逻辑。

在下一篇文章中，我们将讨论如何阅读和调试工作流日志，帮助你更好地理解和排除行动中的问题。感谢你的阅读，我们下次见！