在 buildspec 中使用 GitHub 操作语法 AWS CodeBuild - AWS CodeBuild
如何开始在我的构建规范中使用 GitHub 动作？我可以在我的构建规范中使用哪些 GitHub 操作？除了在 buildspec 中使用 Actions 之外，我 GitHub 还能 GitHub 使用其他源代码提供程序吗？为什么我需要以源代码提供者的 GitHub 身份连接才能在我的构建规范中使用 GitHub 操作？在我的 buildspec 中使用 Ac GitHub tions 要花多少钱？哪些区域支持在我的构建规范中使用 GitHub 操作？在构建规范中使用 GitHub 操作的最佳实践在 buildspec 中使用 GitHub 操作的限制 CodeBuildGitHub 动作运行器构建规范参考GitHub 动作示例

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

在 buildspec 中使用 GitHub 操作语法 AWS CodeBuild

您可以使用 CodeBuild管理的操作运行器在 CodeBuild其中运行 GitHub 操作。这可以通过将 steps 添加到 buildspec 文件中的任何阶段来完成。

CodeBuild buildspecs 支持一系列顺序 GitHub 操作步骤，这些步骤在与 CodeBuild 命令不同的阶段运行。这些 GitHub 操作与 CodeBuild的现有功能集成，包括依赖项缓存、批量构建 AWS Secrets Manager、访问权限等。

如何开始在我的构建规范中使用 GitHub 动作？

在 buildspec 中使用 GitHub 操作的高级步骤如下：

  1. 如果您还没有这样做，请将您的项目连接到 GitHub。

    为此，您可以执行以下操作之一：

    注意

    只有 GitHub 在您尚未连接到其他项目时，才需要执行此操作。

  2. 在项目的 buildspec 中，您可以添加steps，每个配置都引用一个 Acti GitHub on。可以在 CodeBuild 控制台或源存储库中对其进行编辑。各个构建阶段会支持一系列命令或步骤，但同一阶段不会同时支持上述二者。有关更多信息，请参阅 在 buildspec 中使用 GitHub 操作语法 AWS CodeBuild。

我可以在我的构建规范中使用哪些 GitHub 操作？

您可以使用 GitHub Marketplace 中提供的任何与这些限制不冲突的操作。

除了在 buildspec 中使用 Actions 之外，我 GitHub 还能 GitHub 使用其他源代码提供程序吗？

是的，但是仍然需要 GitHub 连接才能使用 GitHub 操作进行身份验证 GitHub和访问。有关更多信息，请参阅 GitHub 和 GitHub 企业服务器访问令牌。

为什么我需要以源代码提供者的 GitHub 身份连接才能在我的构建规范中使用 GitHub 操作？

要在您的构建规范中使用 GitHub 操作，必须将源代码下载到构建计算中。匿名下载将受到速率限制，因此，通过连接 GitHub，它可以帮助确保一致的访问权限。

在我的 buildspec 中使用 Ac GitHub tions 要花多少钱？

支持在 buildspec 中使用 GitHub 操作，无需支付额外费用。

哪些区域支持在我的构建规范中使用 GitHub 操作？

所有 CodeBuild 区域都支持在您的构建规范中使用 GitHub 操作。有关 AWS 区域 何处 CodeBuild 可用的更多信息，请参阅按地区划分的AWS 服务。

在构建规范中使用 GitHub 操作的最佳实践

GitHub Actions 是开源的，由社区构建和维护。我们遵循责任共担模型，并将 A GitHub ctions 源代码视为由您负责的客户数据。 GitHub 可以向操作授予访问密钥、存储库令牌、源代码和账户链接的权限。确保您对计划执行的 GitHub 操作的可信度和安全性充满信心。

针对 GitHub 操作的更具体的指导和安全最佳实践：

在 buildspec 中使用 GitHub 操作的限制 CodeBuild

  • GitHub 不支持 buildsec 中内部依赖于github上下文或引用 GitHub特定资源的操作，例如拉取请求和议题。 CodeBuild例如，以下操作在以下情况下不起作用 CodeBuild：

    • GitHub 尝试添加、更改或更新 GitHub资源的操作，例如更新拉取请求或在中造成问题的操作 GitHub。

    注意

    https://github.com/actions 中列出的大多数官方 GitHub 操作都依赖于github上下文。相反，请使用 GitHub Marketplace 中提供的操作。

  • GitHub 您的 buildspec 中作为 Docker 容器操作的操作将起作用，但是您的构建项目必须启用特权模式并由默认 Docker 用户（root）运行。

  • GitHub 配置为在 Windows 上运行的 CodeBuild 项目不支持构建规范中的操作。

  • GitHub 不支持您的 buildspec 中的 GitHub 操作作业（步骤组）和操作作业属性。

  • GitHub 如果 CodeBuild 项目配置为由公共 Git 存储库的 webhook 触发，则不支持 buildspec 中的操作。有关更多信息，请参阅git-credential-helper。

  • 没有公共互联网访问权限的 VPC 版本无法在您的构建规范中运行 GitHub 操作。

  • 各个构建阶段会支持一系列命令或步骤，但同一阶段不会同时支持上述二者。例如，在以下示例中，在预生成阶段使用步骤列出 GitHub 操作，而在构建阶段使用命令列出 CodeBuild 命令。

    version: 0.2
phases:
  pre-build:
    steps:
      - name: Lint Code Base
        uses: github/super-linter@v4
        env:
          VALIDATE_ALL_CODEBASE: 'true'
          DEFAULT_BRANCH: main
  build:
    commands:
      - echo "Building..."
      - npm run build

GitHub 动作运行器构建规范参考

本主题包含 GitHub 操作运行器属性的构建规范参考。

步骤

可选的序列。步骤用于在中运行命令和操作 CodeBuild。有关更多信息，请参阅 在 buildspec 中使用 GitHub 操作语法 AWS CodeBuild。

注意

各个构建阶段会支持一系列 commands 或 steps，但同一阶段不会同时支持上述二者。

每个构建步骤都包含以下属性。

id

可选。步骤的标识符，可用于从其他上下文中引用该步骤。

if

可选。一种条件语句，可用于阻止运行步骤，除非满足条件。此语句可以使用任何支持的上下文，例如从中 CodeBuild引用环境变量以及表达式。

name

可选。步骤的名称。如果未指定名称，则名称将默认使用 run 命令中指定的文本。

uses

针对该步骤运行的操作。有些操作要求您使用 with 设置输入。参考该操作的自述文件以确定需要哪些输入。有关更多信息，请参阅 我可以在我的构建规范中使用哪些 GitHub 操作？。

如果已在构建阶段指定 uses，则不能将其与 run 一起使用。

注意

建议您提供正在使用的操作版本。您可以通过指定 Git 引用、SHA 或 Docker 标签来执行此操作。有关更多信息，请参阅 steps.uses 语法。

run

运行命令行程序的命令。这些命令可以是单行命令，也可以是多行命令。默认情况下，这些命令使用非登录 shell 运行。要选择其他 shell，请使用 shell。

如果已在构建阶段指定 run，则不能将其与 uses 一起使用。

shell

可选。为此序列指定的 shell。有关支持的 shell 参数，请参阅 steps.shell。如果未指定，则使用的 shell 是 bash。如果 bash 不可用，则使用 sh。

with

可选。由操作定义的输入参数的映射。每个参数由一个键/值对组成。

with.args

可选。定义 Docker 容器输入的字符串。

with.entrypoint

可选。为 Dockerfile 指定的 Docker 入口点。

env

可选。为要在此环境中使用的步骤指定的变量。

continue-on-error

可选。布尔值，用于指示是否可以忽略此步骤序列的故障。

false

默认值。如果此步骤序列失败，则构建失败。

true

如果此步骤序列失败，则构建仍然可能成功。

timeout-minutes

可选。该步骤在终止之前可以运行的最大分钟数。默认情况下，不会设置超时。如果步骤超时超过构建超时，则该步骤将在达到构建超时时停止。

以下是使用 Sup er-Linter 操作的 GitHub 示例：

version: 0.2
phases:
  build:
    steps:
      - name: Lint Code Base
        uses: github/super-linter@v5
        env:
          VALIDATE_ALL_CODEBASE: true
          USE_FIND_ALGORITHM: true
          FILTER_REGEX_INCLUDE: '/github/workspace/buildspec.yml'

GitHub 操作语法示例 AWS CodeBuild

这些样本组可以用来在你的构建规范中 CodeBuild试验 GitHub Actions。

超级林特动作示例 GitHub

此示例演示如何将 Super-Linter GitHub 操作添加到项目中。 CodeBuild Super-Linter 操作会检查代码，找到代码存在错误、格式问题和可疑结构的区域，然后将结果输出到控制台。 CodeBuild

你可以通过更新 buildspec 文件的阶段部分来将 Super-Linter GitHub 操作添加到你的 CodeBuild 项目中。

version: 0.2
phases:
  build:
    steps:
      - name: Lint Code Base
        uses: github/super-linter@v5
        env:
          VALIDATE_ALL_CODEBASE: true

Super-Linter 日志如下所示：

/github/workspace/hello-world/app.js:3:13: Extra semicolon.
/github/workspace/hello-world/app.js:9:92: Trailing spaces not allowed.
/github/workspace/hello-world/app.js:21:7: Unnecessarily quoted property 'body' found.
/github/workspace/hello-world/app.js:31:1: Expected indentation of 2 spaces but found 4.
/github/workspace/hello-world/app.js:32:2: Newline required at end of file but not found.

批量构建图示例

以下示例定义了构建图，展示如何使用 steps 创建依赖项链并运行命令。在此示例中，先运行 build1，因为它没有依赖项。由于 build2 对 build1 存在依赖关系，因此 build2 会在完成 build1 后运行。有关信息，请参阅构建图。

version: 0.2
batch:
  fast-fail: false
  build-graph:
    - identifier: build1
      env:
        variables:
          BUILD_ID: build1
      ignore-failure: false
    - identifier: build2
      env:
        variables:
          BUILD_ID: build2
      depend-on:
        - build1

phases:
  build:
    steps:
      - run: echo $BUILD_ID

Amazon CodeGuru Reviewer 样本

Amazon CodeGuru Reviewer 会在您的 Java 和 Python 代码中发现问题，并建议如何修复这些问题。以下示例使用 CodeGuru Reviewer 提供完整的存储库分析代码审查。这些代码审查会扫描指定分支中的所有代码。有关信息，请参阅 Amazon CodeGuru Reviewer 用户指南中的使用 GitHub 操作创建代码审查。

version: 0.2
phases:
  build:
    steps:
        - name: Amazon CodeGuru Reviewer Scanner
          if: ${{ always() }}
          uses: aws-actions/codeguru-reviewer@v1.1
          with:
            s3_bucket: codeguru-reviewer-user

artifacts:
  files:
    - codeguru-results.sarif.json
注意

Amazon S3 存储桶名称必须以前缀 codeguru-reviewer- 开头。

日志如下所示：

INFO CodeReview created with arn=arn:aws:codeguru-reviewer:region:account-id:association:id:code-review:RepositoryAnalysis-job for job=job
INFO SARIF persisted to /github/workspace/codeguru-results.sarif.json
INFO Amazon CodeGuru Reviewer job execution completed

Amazon CodeGuru Reviewer 任务完成后，将生成一个 sarif 报告作为 CodeBuild 构件。有关信息，请参阅 Amazon CodeGuru Reviewer 用户指南中的完整存储库分析。

AWS Secrets Manager 样本

AWS Secrets Manager 帮助您在数据库凭证、应用程序凭证、OAuth 令牌、API 密钥和其他密钥的整个生命周期中对其进行管理、检索和轮换。以下示例使用 Secrets Manager 定义密钥并使用 steps 运行命令。有关信息，请参阅什么是 AWS Secrets Manager？ 在《AWS Secrets Manager 用户指南》中。

version: 0.2
env:
  secrets-manager:
    SECRET_VALUE: "arn:aws:secretsmanager:us-east-1:xxxx:secret:/secret-l3IJg9:my_super_secret_key"
phases:
  build:
    steps:
      - run: echo $SECRET_VALUE

日志如下所示：

echo $SECRET_VALUE
env:
  SECRET_VALUE: ***
***

环境变量示例

以下示例定义了 env 序列下的环境变量。系统在 buildspec 中定义 S3_BUCKET 变量并分配 <bucket-name> 作为其值。通过使用美元符号 ($) 访问 Acti GitHub on env 上下文，可以像常规环境变量一样在 if 条件中引用此变量。有关更多信息，请参阅 env 序列。

version: 0.2
env:
  variables:
    S3_BUCKET: "<bucket-name>"
phases:
  build:
    steps:
      - if: ${{ env.S3_BUCKET == '<bucket-name>' }}
        run: echo "S3 bucket is $S3_BUCKET"

日志如下所示：

echo "S3 bucket is $S3_BUCKET"
env:
  S3_BUCKET: my-s3-bucket
S3 bucket is my-s3-bucket

导出的环境变量示例

导出的环境变量与结合使用，用于 CodePipeline 将环境变量从当前构建阶段导出到管道的后续阶段。以下示例在名为 MY_VARIABLE 的 env 序列下定义了导出的环境变量，并将其写入 GITHUB_ENV 环境文件。

version: 0.2
env:
  exported-variables:
    - MY_VARIABLE
phases:
  build:
    steps:
      - run: echo "MY_VARIABLE=my-value" >> $GITHUB_ENV

有关更多信息，请参阅 AWS CodeBuild API 参考 ExportedEnvironmentVariable中的。