亚马逊 CodeCatalyst 不再向新买家开放。现有客户可以继续正常使用该服务。有关更多信息，请参阅 [如何从中迁移 CodeCatalyst](migration.md)。
本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 与 GitHub 操作集成
Acti *GitHub on* 很像一个[CodeCatalyst 动作](workflows-actions.md#workflows-actions-types-cc)，不同之处在于它是为与 GitHub 工作流程一起使用而开发的。有关 GitHub 操作的详细信息，请参阅[GitHub 操作](https://docs.github.com/en/actions)文档。
在 CodeCatalyst 工作流程中，您可以将 GitHub CodeCatalyst 操作与原生操作一起使用。
有两种方法可以向 CodeCatalyst 工作流程中添加 GitHub 操作：
+ 您可以从 CodeCatalyst 控制台的精选列表中选择 “ GitHub 操作”。有几种流行的 GitHub 操作可供选择。有关更多信息，请参阅 [添加精心策划 GitHub 的动作](integrations-github-action-add-curated.md)。
+ 如果您要使用的 GitHub 操作在 CodeCatalyst 控制台中不可用，则可以使用 “**GitHub 操作” 操作**将其添加。
***GitHub 操作操作***是一种封装*CodeCatalyst 动作*并使其与 CodeCatalyst 工作流程兼容的 GitHub 动作。
以下是封装 Su [per-Linter](https://github.com/marketplace/actions/super-linter) GitHub 动作的**GitHub 操作操作**示例：
```
Actions:
GitHubAction:
Identifier: aws/github-actions-runner@v1
Configuration:
Steps:
- name: Lint Code Base
uses: github/super-linter@v4
env:
VALIDATE_ALL_CODEBASE: "true"
DEFAULT_BRANCH: main
```
在前面的代码中， CodeCatalyst **GitHub 操作操作**（由标识`aws/github-actions-runner@v1`）封装了 Super-Linter 操作（由标识`github/super-linter@v4`），使其在工作流程中起作用。 CodeCatalyst
有关更多信息，请参阅 [添加 “GitHub 操作” 操作](integrations-github-action-add.md)。
所有 GitHub 动作（无论是否精选）都必须封装在 Actions 动**GitHub 作** (`aws/github-actions-runner@v1`) 中，如前面的示例所示。此操作需要包装程序才能正常运行。
**Topics**
+ [GitHub 动作与动作有何不同 CodeCatalyst ？](#integrations-github-actions-how-different)
+ [GitHub 操作能否与工作流程中的其他 CodeCatalyst 操作进行交互？](#integrations-github-actions-interactions.title)
+ [我可以使用哪些 GitHub 操作？](#integrations-github-actions-supported)
+ [GitHub 操作的局限性 CodeCatalyst](#integrations-github-actions-limitations)
+ [如何添加 GitHub 操作（高级步骤）？](#integrations-github-actions-how-to)
+ [GitHub 动作会运行 GitHub吗？](#integrations-github-actions-where-it-runs)
+ [我也可以使用 GitHub 工作流程吗？](#integrations-github-actions-workflows-support.title)
+ [“GitHub 动作” 操作使用的运行时镜像](#integrations-github-actions-runtime)
+ [教程：使用动作的 Lint 代码 GitHub](integrations-github-action-tutorial.md)
+ [添加 “GitHub 操作” 操作](integrations-github-action-add.md)
+ [添加精心策划 GitHub 的动作](integrations-github-action-add-curated.md)
+ [导出 GitHub 输出参数](integrations-github-action-export.md)
+ [引用 GitHub 输出参数](integrations-github-action-referencing.md)
+ ['GitHub Actions'动作 YAML](github-action-ref.md)
## GitHub 动作与动作有何不同 CodeCatalyst ？
GitHub 在 CodeCatalyst 工作流程中使用的操作与 CodeCatalyst 操作的访问权限和集成级别 AWS 以及 CodeCatalyst 功能（例如[环境](deploy-environments.md)和[问题](issues.md)）不同。
## GitHub 操作能否与工作流程中的其他 CodeCatalyst 操作进行交互？
可以。例如， GitHub Actions 可以使用其他 CodeCatalyst 操作生成的变量作为输入，也可以将输出参数和构件与 CodeCatalyst 操作共享。有关更多信息，请参阅[导出 GitHub 输出参数](integrations-github-action-export.md)和[引用 GitHub 输出参数](integrations-github-action-referencing.md)。
## 我可以使用哪些 GitHub 操作？
您可以使用 CodeCatalyst 控制台提供的任何 GitHub 操作以及 [GitHubMarketplace](https://github.com/marketplace/actions) 中可用的任何 GitHub 操作。如果您决定使用 Marketplace 中的 GitHub 操作，请记住以下[限制](#integrations-github-actions-limitations)。
## GitHub 操作的局限性 CodeCatalyst
+ GitHub 操作不能与 CodeCatalyst [Lambda 计算](workflows-working-compute.md#compute.types)类型一起使用。
+ GitHub 操作在 [2022 年 11 月](build-images.md#build.previous-image)的运行时环境 Docker 镜像上运行，其中包括较旧的工具。有关映像和工具的更多信息，请参阅[指定运行时环境映像](build-images.md)。
+ GitHub 内部依赖于[`github`上下文](https://docs.github.com/en/actions/learn-github-actions/contexts#github-context)或引用 GitHub特定资源的操作在中不起作用。 CodeCatalyst例如，以下操作在以下情况下不起作用 CodeCatalyst：
+ 尝试添加、更改或更新 GitHub 资源的操作。示例包括更新拉取请求或在中创建问题的操作 GitHub。
+ 几乎所有操作都列在 [https://github.com/actions](https://github.com/actions) 中。
+ GitHub 作为 [Docker 容器操作的操作](https://docs.github.com/en/actions/creating-actions/about-custom-actions#docker-container-actions)可以运行，但必须由默认 Docker 用户（root）运行。请不要以用户 1001 的身份运行此操作。（在撰写本文时，用户 1001 在中工作 GitHub，但不在中 CodeCatalyst。） 有关更多信息，请参阅 [Dockerfile 操作支持 GitHub ](https://docs.github.com/en/actions/creating-actions/dockerfile-support-for-github-actions)中的[用户](https://docs.github.com/en/actions/creating-actions/dockerfile-support-for-github-actions#user)主题。
有关可通过 CodeCatalyst 控制台 GitHub 执行的操作的列表，请参阅[添加精心策划 GitHub 的动作](integrations-github-action-add-curated.md)。
## 如何添加 GitHub 操作（高级步骤）？
向 CodeCatalyst 工作流程添加 GitHub 操作的高级步骤如下：
1. 在您的 CodeCatalyst 项目中，您可以**创建工作流程**。在工作流中，您可以定义如何构建、测试和部署应用程序。有关更多信息，请参阅 [入门工作流](workflows-getting-started.md)。
1. 在工作流程中，您可以**添加精心策划的 GitHub 操作**或**添加 GitHub 操作操作**。
1. 您可以执行下列操作之一：
+ 如果您选择添加一个经策管操作，请配置该操作。有关更多信息，请参阅 [添加精心策划 GitHub 的动作](integrations-github-action-add-curated.md)。
+ 如果您选择添加非精选动作，则在**GitHub操作操作中粘贴该 GitHub 操作****的 YAM** L 代码。您可以在 M [GitHubarketplac](https://github.com/marketplace/actions) e 中选择的 GitHub操作的详情页面上找到此代码。你可能需要稍微修改一下代码才能让它发挥作用 CodeCatalyst。有关更多信息，请参阅 [添加 “GitHub 操作” 操作](integrations-github-action-add.md)。
1. （可选）在工作流中，**您可以添加其他操作**，例如构建和测试操作。有关更多信息，请参阅 [使用工作流进行构建、测试和部署使用工作流进行构建、测试和部署](workflow.md)。
1. 您可以手动**启动工作流**，也可以通过触发器自动启动工作流。工作流程运行 GitHub 操作和工作流程中的任何其他操作。有关更多信息，请参阅 [手动启动工作流运行](workflows-manually-start.md)。
有关详细步骤，请参阅：
+ [添加精心策划 GitHub 的动作](integrations-github-action-add-curated.md).
+ [添加 “GitHub 操作” 操作](integrations-github-action-add.md).
## GitHub 动作会运行 GitHub吗？
不是。 Acti GitHub on 在中运行 CodeCatalyst，使用 CodeCatalyst[运行时环境镜像](workflows-working-compute.md)。
## 我也可以使用 GitHub 工作流程吗？
否。
## “GitHub 动作” 操作使用的运行时镜像
CodeCatalyst **GitHub 操作操作**在 [2022 年 11 月的图像](build-images.md#build.previous-image)上运行。有关更多信息，请参阅 [活动映像](build-images.md#build-curated-images)。
# 教程：使用动作的 Lint 代码 GitHub
在本教程中，您将将 [Super-Linter GitHub 操作](https://github.com/marketplace/actions/super-linter)添加到亚马逊 CodeCatalyst 工作流程中。Super-Linter 操作检查代码，查找代码存在错误、格式问题和可疑结构的区域，然后将结果输出到控制台）。 CodeCatalyst将 linter 添加到工作流后，您可以运行工作流来对示例 Node.js 应用程序（`app.js`）进行 lint 检查。之后，您可以修复报告的问题，并再次运行工作流以查看是否已成功修复问题。
**提示**
考虑使用 Super-Linter 来对 YAML 文件（例如 [CloudFormation 模板](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html)）进行 lint 检查。
**Topics**
+ [先决条件](#integrations-github-action-tutorial-prereqs)
+ [步骤 1：创建源存储库](#integrations-github-action-tutorial-create-source-repo)
+ [步骤 2：添加 app.js 文件](#integrations-github-action-tutorial-add-appjs)
+ [步骤 3：创建运行 Super-Linter 操作的工作流](#integrations-github-action-tutorial-create-workflow)
+ [步骤 4：修复 Super-Linter 发现的问题](#integrations-github-action-tutorial-fix-probs)
+ [清理](#integrations-github-action-tutorial-cleanup)
## 先决条件
在开始之前，您需要：
+ 一个连接的 CodeCatalyst **空间** AWS 账户。有关更多信息，请参阅 [创建空间](spaces-create.md)。
+ 您的 CodeCatalyst 空间中有一个名为的空项目`codecatalyst-linter-project`。选择**从头开始**选项来创建此项目。
```
```
有关更多信息，请参阅 [在 Amazon 中创建一个空项目 CodeCatalyst](projects-create.md#projects-create-empty)。
## 步骤 1：创建源存储库
在此步骤中，您将在中创建源存储库 CodeCatalyst。您将使用此存储库来存储示例应用程序源文件（本教程中为 `app.js`）。
有关源存储库的更多信息，请参阅[创建源存储库](source-repositories-create.md)。
**创建源存储库**
1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。
1. 导航到您的项目 `codecatalyst-linter-project`。
1. 在导航窗格中，选择**代码**，然后选择**源存储库**。
1. 选择**添加存储库**，然后选择**创建存储库**。
1. 在**存储库名称**中，输入：
```
codecatalyst-linter-source-repository
```
1. 选择**创建**。
## 步骤 2：添加 app.js 文件
在此步骤中，您将 `app.js` 文件添加到源存储库。`app.js` 包含的函数代码存在几处错误，linter 将发现这些错误。
**添加 app.js 文件**
1. 在 CodeCatalyst 控制台中，选择您的项目`codecatalyst-linter-project`。
1. 在导航窗格中，选择**代码**，然后选择**源存储库**。
1. 从源存储库列表中，选择您的存储库 `codecatalyst-linter-source-repository`。
1. 在**文件**中，选择**创建文件**。
1. 在文本框中，输入以下代码：
```
// const axios = require('axios')
// const url = 'http://checkip.amazonaws.com/';
let response;
/**
*
* Event doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html#api-gateway-simple-proxy-for-lambda-input-format
* @param {Object} event - API Gateway Lambda Proxy Input Format
*
* Context doc: https://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-context.html
* @param {Object} context
*
* Return doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html
* @returns {Object} object - API Gateway Lambda Proxy Output Format
*
*/
exports.lambdaHandler = async (event, context) => {
try {
// const ret = await axios(url);
response = {
statusCode: 200,
'body': JSON.stringify({
message: 'hello world'
// location: ret.data.trim()
})
}
} catch (err) {
console.log(err)
return err
}
return response
}
```
1. 对于**文件名**，输入 `app.js`。保留其他默认选项。
1. 选择**提交**。
现在，您已创建一个名为 `app.js` 的文件。
## 步骤 3：创建运行 Super-Linter 操作的工作流
在此步骤中，您将创建一个工作流，当您将代码推送到源存储库时，该工作流将运行 Super-Linter 操作。该工作流包含您在 YAML 文件中定义的以下构建基块：
+ **触发器** – 当您将更改推送到源存储库时，此触发器会自动启动工作流运行。有关触发器的更多信息，请参阅[使用触发器自动启动工作流运行](workflows-add-trigger.md)。
+ **“GitHub 操作” 操作** — 触发后，“**GitHub 操作**” 操作会运行 Super-Linter 操作，该操作反过来会检查源存储库中的所有文件。如果 linter 发现问题，则工作流操作将失败。
**创建运行 Super-Linter 操作的工作流**
1. 在 CodeCatalyst 控制台中，选择您的项目`codecatalyst-linter-project`。
1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。
1. 选择**创建工作流**。
1. 对于**源存储库**，选择 `codecatalyst-linter-source-repository`。
1. 对于**分支**，选择 `main`。
1. 选择**创建**。
1. 删除 YAML 示例代码。
1. 添加以下 YAML：
```
Name: codecatalyst-linter-workflow
SchemaVersion: "1.0"
Triggers:
- Type: PUSH
Branches:
- main
Actions:
SuperLinterAction:
Identifier: aws/github-actions-runner@v1
Configuration:
Steps:
github-action-code
```
在前面的代码中，按照本*github-action-code*过程的以下步骤中的说明替换为 Super-Linter 操作代码。
1. 前往 Market [place GitHub 中的 Super-Linter 页面](https://github.com/marketplace/actions/super-linter)。
1. 在`steps:`（小写）下，找到代码并将其粘贴到`Steps:`（大写）下 CodeCatalyst的工作流程中。
调整 GitHub 操作代码以符合 CodeCatalyst 标准，如以下代码所示。
现在，您的 CodeCatalyst 工作流程如下所示：
```
Name: codecatalyst-linter-workflow
SchemaVersion: "1.0"
Triggers:
- Type: PUSH
Branches:
- main
Actions:
SuperLinterAction:
Identifier: aws/github-actions-runner@v1
Configuration:
Steps:
- name: Lint Code Base
uses: github/super-linter@v4
env:
VALIDATE_ALL_CODEBASE: "true"
DEFAULT_BRANCH: main
```
1. （可选）选择**验证**，确保 YAML 代码在提交之前有效。
1. 选择**提交**，输入**提交消息**，选择您的 `codecatalyst-linter-source-repository` **存储库**，然后再次选择**提交**。
现在，您已创建工作流。由于在工作流顶部定义了触发器，因此工作流运行会自动启动。
**查看正在运行的工作流**
1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。
1. 选择您刚刚创建的工作流：`codecatalyst-linter-workflow`。
1. 在工作流程图中，选择**SuperLinterAction**。
1. 等待操作失败。预计会失败，因为 linter 在代码中发现了问题。
1. 让 CodeCatalyst 控制台保持打开状态并转至[步骤 4：修复 Super-Linter 发现的问题](#integrations-github-action-tutorial-fix-probs)。
## 步骤 4：修复 Super-Linter 发现的问题
Super-Linter 应已在 `app.js` 代码以及源代码库中包含的 `README.md` 文件中发现了问题。
**解决 linter 发现的问题**
1. 在 CodeCatalyst 控制台中，选择 “**日志**” 选项卡，然后选择 **Lint Code Base**。
这将显示 Super-Linter 操作生成的日志。
1. 在 Super-Linter 日志中，向下滚动到第 90 行左右，您可以从该行开始查看问题。其内容与以下内容类似：
```
/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.
```
1. 修复源存储库中的 `app.js` 和 `README.md`，然后提交您的更改。
**提示**
要修复 `README.md`，请在代码块中添加 `markdown`，如下所示：
```
```markdown
Setup examples:
...
```
```
您的更改将自动启动另一个工作流。等待该工作流完成。如果您已修复所有问题，则该工作流将成功。
## 清理
进行清理 CodeCatalyst 以从您的环境中删除本教程的痕迹。
**要清理干净 CodeCatalyst**
1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。
1. 删除 `codecatalyst-linter-source-repository`。
1. 删除 `codecatalyst-linter-workflow`。
在本教程中，你学习了如何将 Super-Linter GitHub 操作添加到 CodeCatalyst 工作流程中以整理一些代码。
# 添加 “GitHub 操作” 操作
***GitHub 操作操作***是一种封装*CodeCatalyst 动作*并使其与 CodeCatalyst 工作流程兼容的 GitHub 动作。
有关更多信息，请参阅 [与 GitHub 操作集成](integrations-github-actions.md)。
要将 “**GitHub 操作” 操作**添加到工作流程，请执行以下步骤。
**提示**
有关向您展示如何使用 “**GitHub 操作” 操作**的教程，请参阅[教程：使用动作的 Lint 代码 GitHub](integrations-github-action-tutorial.md)。
------
#### [ Visual ]
**使用可视化编辑器添加 “GitHub 操作” 动作**
1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。
1. 选择您的项目。
1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。
1. 选择工作流的名称。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。
1. 选择**编辑**。
1. 选择**可视化**。
1. 在左上角，选择 **\$1 操作**打开操作目录。
1. 从下拉列表中选择**GitHub**。
1. 搜索 “**GitHub 操作**” 操作，然后执行以下任一操作：
+ 选择加号（**\$1**），将操作添加到工作流图表中并打开其配置窗格。
或
+ 选择**GitHub 操作**。此时会显示操作详细信息对话框。在此对话框中：
+ （可选）选择**查看源**以[查看操作的源代码](workflows-view-source.md#workflows-view-source.title)。
+ 选择**添加到工作流**，将操作添加到工作流图表中并打开其配置窗格。
1. 在**输入**和**配置**选项卡中，根据需要填写字段。有关每个字段的描述，请参阅['GitHub Actions'动作 YAML](github-action-ref.md)。本参考提供了有关在 YAML 编辑器和可视化编辑器中显示的每个字段（以及对应的 YAML 属性值）的详细信息。
1. （可选）选择**验证**，在提交之前验证工作流的 YAML 代码。
1. 选择**提交**，输入提交消息，然后再次选择**提交**。
------
#### [ YAML ]
**使用 YAML 编辑器添加 “GitHub 操作” 操作**
1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。
1. 选择您的项目。
1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。
1. 选择工作流的名称。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。
1. 选择**编辑**。
1. 选择 **YAML**。
1. 在左上角，选择 **\$1 操作**打开操作目录。
1. 从下拉列表中选择**GitHub**。
1. 搜索 “**GitHub 操作**” 操作，然后执行以下任一操作：
+ 选择加号（**\$1**），将操作添加到工作流图表中并打开其配置窗格。
或
+ 选择**GitHub 操作**。此时会显示操作详细信息对话框。在此对话框中：
+ （可选）选择**查看源**以[查看操作的源代码](workflows-view-source.md#workflows-view-source.title)。
+ 选择**添加到工作流**，将操作添加到工作流图表中并打开其配置窗格。
1. 根据需求修改 YAML 代码中的属性。['GitHub Actions'动作 YAML](github-action-ref.md)中提供了每个可用属性的解释。
1. （可选）选择**验证**，在提交之前验证工作流的 YAML 代码。
1. 选择**提交**，输入提交消息，然后再次选择**提交**。
------
## 'GitHub 操作'动作定义
**GitHub 操作操作**定义为工作流程定义文件中的一组 YAML 属性。有关这些属性的信息，请参阅[工作流 YAML 定义](workflow-reference.md)中的['GitHub Actions'动作 YAML](github-action-ref.md)。
# 添加精心策划 GitHub 的动作
*策划的 GitHub 操作*是在 CodeCatalyst 控制台中可用的 GitHub 操作，可作为如何在 CodeCatalyst工作流程中使用 GitHub 操作的示例。
策划的 GitHub 操作被封装在由标识符标识的 CodeCatalyst-authored Actions [**GitHub 操作**](integrations-github-action-add.md)中。`aws/github-actions-runner@v1`例如，以下是精心策划的 Acti GitHub on [TruffleHog OSS](https://github.com/marketplace/actions/trufflehog-oss) 的样子：
```
Actions:
TruffleHogOSS_e8:
Identifier: aws/github-actions-runner@v1
Inputs:
Sources:
- WorkflowSource # This specifies that the action requires this Workflow as a source
Configuration:
Steps:
- uses: trufflesecurity/trufflehog@v3.16.0
with:
path: ' ' # Required; description: Repository path
base: ' ' # Required; description: Start scanning from here (usually main branch).
head: ' ' # Optional; description: Scan commits until here (usually dev branch).
extra_args: ' ' # Optional; description: Extra args to be passed to the trufflehog cli.
```
在前面的代码中，Actions CodeCatalyst **GitHub 操作**（由标识`aws/github-actions-runner@v1`）封装 TruffleHog OSS 操作（由标识`trufflesecurity/trufflehog@v3.16.0`），使其在工作 CodeCatalyst 流程中运行。
要配置此操作，您需要将 `with:` 下的空字符串替换为您自己的值。例如：
```
Actions:
TruffleHogOSS_e8:
Identifier: aws/github-actions-runner@v1
Inputs:
Sources:
- WorkflowSource # This specifies that the action requires this Workflow as a source
Configuration:
Steps:
- uses: trufflesecurity/trufflehog@v3.16.0
with:
path: ./
base: main # Required; description: Start scanning from here (usually main branch).
head: HEAD # Optional; description: Scan commits until here (usually dev branch).
extra_args: '‐‐debug ‐‐only-verified' # Optional; description: Extra args to be passed to the trufflehog cli.
```
要将精心策划的 GitHub 操作添加到工作流程，请按以下步骤操作。有关在 CodeCatalyst 工作流程中使用 GitHub 操作的一般信息，请参阅[与 GitHub 操作集成](integrations-github-actions.md)。
**注意**
如果您在精选操作列表中看不到您的 GitHub 操作，您仍然可以使用 “操作” **GitHub 操作**将其添加到工作流程中。有关更多信息，请参阅 [添加 “GitHub 操作” 操作](integrations-github-action-add.md)。
------
#### [ Visual ]
**使用可视化编辑器添加精选 GitHub 动作**
1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。
1. 选择您的项目。
1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。
1. 选择工作流的名称。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。
1. 选择**编辑**。
1. 选择**可视化**。
1. 在左上角，选择 **\$1 操作**打开操作目录。
1. 从下拉列表中选择**GitHub**。
1. 浏览或搜索某项 GitHub 操作，然后执行以下任一操作：
+ 选择加号（**\$1**），将操作添加到工作流图表中并打开其配置窗格。
或
+ 选择 GitHub 操作的名称。此时会显示操作详细信息对话框。在此对话框中：
+ （可选）选择**查看源**以[查看操作的源代码](workflows-view-source.md#workflows-view-source.title)。
+ 选择**添加到工作流**，将操作添加到工作流图表中并打开其配置窗格。
1. 在**输入**、**配置**和**输出**选项卡中，根据需要填写字段。有关每个字段的描述，请参阅['GitHub Actions'动作 YAML](github-action-ref.md)。本参考提供了有关 “**GitHub操作**” 操作中可用的每个字段（以及相应的 YAML 属性值）的详细信息，因为该字段同时出现在 YAML 和可视编辑器中。
有关策划的 Acti GitHub on 可用的配置选项的信息，请参阅其文档。
1. （可选）选择**验证**，在提交之前验证工作流的 YAML 代码。
1. 选择**提交**，输入提交消息，然后再次选择**提交**。
------
#### [ YAML ]
**使用 YAML 编辑器添加精选 GitHub 动作**
1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。
1. 选择您的项目。
1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。
1. 选择工作流的名称。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。
1. 选择**编辑**。
1. 选择 **YAML**。
1. 在左上角，选择 **\$1 操作**打开操作目录。
1. 从下拉列表中选择**GitHub**。
1. 浏览或搜索某项 GitHub 操作，然后执行以下任一操作：
+ 选择加号（**\$1**），将操作添加到工作流图表中并打开其配置窗格。
或
+ 选择 GitHub 操作的名称。此时会显示操作详细信息对话框。在此对话框中：
+ （可选）选择**查看源**以[查看操作的源代码](workflows-view-source.md#workflows-view-source.title)。
+ 选择**添加到工作流**，将操作添加到工作流图表中并打开其配置窗格。
1. 根据需求修改 YAML 代码中的属性。中提供了对 “**GitHub 操作” 操作**可用的每个属性的解释['GitHub Actions'动作 YAML](github-action-ref.md)。
有关策划的 Acti GitHub on 可用的配置选项的信息，请参阅其文档。
1. （可选）选择**验证**，在提交之前验证工作流的 YAML 代码。
1. 选择**提交**，输入提交消息，然后再次选择**提交**。
------
# 导出 GitHub 输出参数
您可以在 CodeCatalyst 工作流中使用 [GitHub 输出参数](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter)。
**注意**
*输出参数*的另一个词是*变量*。由于 GitHub 在其文档中使用了术语*输出参数*，因此我们也将使用此术语。
按照以下说明操作，从 GitHub Action 中导出 GitHub 输出参数，以便其他 CodeCatalyst 工作流操作可以使用该参数。
**导出 GitHub 输出参数**
1. 打开工作流并选择**编辑**。有关更多信息，请参阅 [创建工作流](workflows-create-workflow.md)。
1. 在生成要导出的输出参数的 **GitHub Actions** 操作中，添加一个包含基础 `Variables` 属性的 `Outputs` 部分，如下所示：
```
Actions:
MyGitHubAction:
Identifier: aws/github-actions-runner@v1
Outputs:
Variables:
- 'step-id_output-name'
```
进行如下替换：
+ 将 *step-id* 替换为 GitHub 操作的 `steps` 部分中的 `id:` 属性的值。
+ 将 *output-name* 替换为 GitHub 输出参数的名称。
**示例**
以下示例演示如何导出名为 `SELECTEDCOLOR` 的 GitHub 输出参数。
```
Actions:
MyGitHubAction:
Identifier: aws/github-actions-runner@v1
Outputs:
Variables:
- 'random-color-generator_SELECTEDCOLOR'
Configuration:
Steps:
- name: Set selected color
run: echo "SELECTEDCOLOR=green" >> $GITHUB_OUTPUT
id: random-color-generator
```
# 引用 GitHub 输出参数
使用以下说明来引用 GitHub 输出参数。
**引用 GitHub 输出参数**
1. 完成 [导出 GitHub 输出参数](integrations-github-action-export.md) 中的步骤。
GitHub 输出参数现在可用于其他操作。
1. 记下输出参数的 `Variables` 值。它包含下划线（\$1）。
1. 使用以下语法引用输出参数：
```
${action-name.output-name}
```
进行如下替换：
+ *action-name*使用生成输出参数的 Acti CodeCatalyst **GitHub on** 的名称（不要使用 GitHub 操作的`name`或`id`）。
+ *output-name*使用你之前记下的输出参数的`Variables`值。
**示例**
```
BuildActionB:
Identifier: aws/build@v1
Configuration:
Steps:
- Run: echo ${MyGitHubAction.random-color-generator_SELECTEDCOLOR}
```
**带上下文的示例**
以下示例说明如何在 `GitHubActionA` 中设置 `SELECTEDCOLOR` 变量、输出该变量，然后在 `BuildActionB` 中引用该变量。
```
Actions:
GitHubActionA:
Identifier: aws/github-actions-runner@v1
Configuration:
Steps:
- name: Set selected color
run: echo "SELECTEDCOLOR=green" >> $GITHUB_OUTPUT
id: random-color-generator
Outputs:
Variables:
- 'random-color-generator_SELECTEDCOLOR'
BuildActionB:
Identifier: aws/build@v1
Configuration:
Steps:
- Run: echo ${GitHubActionA.random-color-generator_SELECTEDCOLOR}
```
# 'GitHub Actions'动作 YAML
以下是 “**GitHub操作**” 操作的 YAML 定义。
此操作定义部分包含在更广泛的工作流定义文件中。有关此文件的更多信息，请参阅[工作流 YAML 定义](workflow-reference.md)。
在以下代码中选择一个 YAML 属性可查看其描述。
**注意**
接下来的大多数 YAML 属性在可视化编辑器中都有对应的 UI 元素。要查找 UI 元素，请使用 **Ctrl\$1F**。该元素将与其关联的 YAML 属性一起列出。
```
# The workflow definition starts here.
# See 顶级属性 for details.
Name: MyWorkflow
SchemaVersion: 1.0
Actions:
# The action definition starts here.
action-name:
Identifier: aws/github-actions-runner@v1
DependsOn:
- dependent-action-name-1
Compute:
Fleet: fleet-name
Timeout: timeout-minutes
Environment:
Name: environment-name
Connections:
- Name: account-connection-name
Role: iam-role-name
Inputs:
Sources:
- source-name-1
- source-name-2
Artifacts:
- artifact-name
Variables:
- Name: variable-name-1
Value: variable-value-1
- Name: variable-name-2
Value: variable-value-2
Outputs:
Artifacts:
- Name: output-artifact-1
Files:
- github-output/artifact-1.jar
- "github-output/build*"
- Name: output-artifact-2
Files:
- github-output/artifact-2.1.jar
- github-output/artifact-2.2.jar
Variables:
- variable-name-1
- variable-name-2
AutoDiscoverReports:
Enabled: true | false
ReportNamePrefix: AutoDiscovered
IncludePaths:
- "**/*"
ExcludePaths:
- node_modules/cdk/junit.xml
SuccessCriteria:
PassRate: percent
LineCoverage: percent
BranchCoverage: percent
Vulnerabilities:
Severity: CRITICAL|HIGH|MEDIUM|LOW|INFORMATIONAL
Number: whole-number
Reports:
report-name-1:
Format: format
IncludePaths:
- "*.xml"
ExcludePaths:
- report2.xml
- report3.xml
SuccessCriteria:
PassRate: percent
LineCoverage: percent
BranchCoverage: percent
Vulnerabilities:
Severity: CRITICAL|HIGH|MEDIUM|LOW|INFORMATIONAL
Number: whole-number
Configuration
Steps:
- github-actions-code
```
## action-name
（必需）
指定操作的名称。工作流中的所有操作名称都必须是唯一的。操作名称仅限于字母数字字符（a-z、A-Z、0-9）、连字符（-）和下划线（\$1）。不允许使用空格。不能使用引号在操作名称中包含特殊字符和空格。
对应的 UI：“配置” 选项卡/ *action-name*
## Identifier
(*action-name*/**Identifier**)
标识操作。除非您要更改版本，否则不要更改此属性。有关更多信息，请参阅 [指定要使用的操作版本](workflows-action-versions.md)。
`aws/github-actions-runner@v1`用于**GitHub操作**操作。
对应的用户界面：工作流程图// **aws*action-name*/@v1 标签 github-actions-runner**
## DependsOn
(*action-name*/**DependsOn**)
（可选）
指定必须成功运行才能使该操作运行的操作、操作组或阶段门。
有关“依赖于”功能的更多信息，请参阅[顺序操作](workflows-depends-on.md)。
对应的 UI：“输入”选项卡/**依赖于 – 可选**
## Compute
(*action-name*/**Compute**)
（可选）
用于运行工作流操作的计算引擎。您可以在工作流级别或操作级别指定计算，但不能同时在这两个级别指定计算。在工作流级别指定计算时，计算配置将应用于工作流中定义的所有操作。在工作流级别，您还可以在同一个实例上运行多个操作。有关更多信息，请参阅[跨操作共享计算](compute-sharing.md)。
对应的 UI：*无*
## Fleet
(*action-name*/Compute/**Fleet**)
（可选）
指定将运行您的工作流或工作流操作的计算机或实例集。对于按需实例集，当操作开始时，工作流会预置操作所需的资源，操作完成后计算机就会被销毁。按需实例集的示例：`Linux.x86-64.Large`、`Linux.x86-64.XLarge`。有关按需实例集的更多信息，请参阅[按需实例集属性](workflows-working-compute.md#compute.on-demand)。
使用预置的实例集，您可以配置一组专用计算机来运行工作流操作。这些计算机保持空闲状态，可随时开始立即处理操作。有关预置实例集的更多信息，请参阅[预置实例集属性](workflows-working-compute.md#compute.provisioned-fleets)。
如果省略 `Fleet`，则默认值为 `Linux.x86-64.Large`。
对应的 UI：“配置”选项卡/**计算实例集 – 可选**
## Timeout
(*action-name*/**Timeout**)
（可选）
指定操作在 CodeCatalyst 结束操作之前可以运行的时间（以分钟（YAML 编辑器）或小时和分钟（可视化编辑器）为单位。最小值为 5 分钟，最大值如 [中的工作流程配额 CodeCatalyst](workflows-quotas.md) 中描述。默认超时值与最大超时值相同。
对应的 UI：“配置”选项卡/**超时 – 可选**
## Environment
(*action-name*/**Environment**)
（可选）
指定要用于操作的 CodeCatalyst 环境。该操作连接到在所选环境中指定的 AWS 账户 和可选的 Amazon VPC。该操作使用环境中指定的默认 IAM 角色连接到 AWS 账户，并使用在 A [mazon VPC 连接](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)中指定的 IAM 角色连接到亚马逊 VPC。
**注意**
如果默认 IAM 角色不具有操作所需的权限，则可以将操作配置为使用其他角色。有关更多信息，请参阅[更改操作的 IAM 角色](deploy-environments-switch-role.md)。
有关环境的更多信息，请参阅[部署到 AWS 账户 和 VPCs](deploy-environments.md)和[创建环境](deploy-environments-creating-environment.md)。
对应的 UI：“配置”选项卡/**环境**
## Name
(*action-name*/Environment/**Name**)
（如果包含 [Environment](#github.environment)，则为必需）
指定要与操作关联的现有环境的名称。
对应的 UI：“配置”选项卡/**环境**
## Connections
(*action-name*/Environment/**Connections**)
（可选）
指定要与操作关联的账户连接。您在 `Environment` 下最多只能指定一个账户连接。
如果您不指定账户连接：
+ 该操作使用 CodeCatalyst 控制台中环境中指定的 AWS 账户 连接和默认 IAM 角色。有关向环境添加账户连接和默认 IAM 角色的信息，请参阅[创建环境](deploy-environments-creating-environment.md)。
+ 默认 IAM 角色必须包含操作所需的策略和权限。要具体确定这些策略和权限，请参阅操作的 YAML 定义文档中 **Role** 属性的描述。
有关账户连接的更多信息，请参阅[允许在已连接的情况下访问 AWS 资源 AWS 账户](ipa-connect-account.md)。有关向环境添加账户连接的信息，请参阅[创建环境](deploy-environments-creating-environment.md)。
对应的用户界面：配置在tab/Environment/What里面*my-environment*吗？ **/三点菜单/ 切换角色**
## Name
(*action-name*/Environment/Connections/**Name**)
（如果包含 [Connections](#github.environment.connections)，则为必需）
指定账户连接的名称。
对应的用户界面：配置在tab/Environment/What里面*my-environment*吗？ **/三点菜单/ 切换角色**
## Role
(*action-name*/Environment/Connections/**Role**)
（如果包含 [Connections](#github.environment.connections)，则为必需）
指定 IAM 角色的名称，该操作使用此角色来访问 Amazon S3 和 Amazon ECR 等 AWS 服务并在其中进行处理。确保将此角色添加到空间中的 AWS 账户 连接。要向账户连接添加 IAM 角色，请参阅[将 IAM 角色添加到账户连接](ipa-connect-account-addroles.md)。
如果您未指定 IAM 角色，则该操作将使用 CodeCatalyst 控制台中[环境](deploy-environments.md)中列出的默认 IAM 角色。如果您使用此环境中的默认角色，请确保该角色具有以下策略。
**注意**
您可以将 `CodeCatalystWorkflowDevelopmentRole-spaceName` 角色用于此操作。有关该角色的更多信息，请参阅[为您的账户和空间创建 **CodeCatalystWorkflowDevelopmentRole-*spaceName*** 角色](ipa-iam-roles.md#ipa-iam-roles-service-create)。了解 `CodeCatalystWorkflowDevelopmentRole-spaceName` 角色具有完全访问权限可能会带来安全风险。我们建议您仅在教程和安全要求较低的场景中使用此角色。
**警告**
将权限限制为 “**GitHub 操作” 操作**所需的权限。使用具有更广泛权限的角色可能会带来安全风险。
对应的用户界面：配置在tab/Environment/What里面*my-environment*吗？ **/三点菜单/ 切换角色**
## Inputs
(*action-name*/**Inputs**)
（可选）
`Inputs` 部分中定义了工作流运行期间操作所需的数据。
**注意**
每个 “**GitHub 操作**” 操作最多允许四个输入（一个源和三个构件）。变量不计入此总数。
如果您需要引用驻留在不同输入（例如源和构件）中的文件，则源输入是主输入，构件是辅助输入。辅助输入中对文件的引用采用特殊前缀，以与主输入中的文件区分开来。有关更多信息，请参阅 [示例：引用多个构件中的文件](workflows-working-artifacts-ex.md#workflows-working-artifacts-ex-ref-file)。
对应的 UI：**输入**选项卡
## Sources
(*action-name*/Inputs/**Sources**)
（可选）
指定表示操作所需的源存储库的标签。当前，支持的唯一标签是 `WorkflowSource`，它表示存储工作流定义文件的源存储库。
如果省略源，则必须在 `action-name/Inputs/Artifacts` 下至少指定一个输入构件。
有关来源的更多信息，请参阅[将源存储库连接到工作流](workflows-sources.md)。
对应的 UI：“输入”选项卡/**来源 – 可选**
## Artifacts - input
(*action-name*/Inputs/**Artifacts**)
（可选）
指定以前操作中的一些构件，您希望将这些构件用作此操作的输入。这些构件必须已在以前的操作中定义为输出构件。
如果未指定任何输入构件，则必须在 `action-name/Inputs/Sources` 下指定至少一个源存储库。
有关构件的更多信息（包括示例），请参阅[在操作之间共享构件和文件](workflows-working-artifacts.md)。
**注意**
如果**构件 – 可选**下拉列表不可用（可视化编辑器），或者在验证 YAML 时出现错误（YAML 编辑器），这可能是因该操作仅支持一个输入导致的。在这种情况下，请尝试移除源输入。
对应的 UI：“输入”选项卡/**构件 – 可选**
## Variables - input
(*action-name*/Inputs/**Variables**)
（可选）
指定一系列 name/value 对，用于定义要提供给操作的输入变量。变量名称仅限字母数字字符（a-z、A-Z、0-9）、连字符（-）和下划线（\$1）。不允许使用空格。不能使用引号以使变量名能够包含特殊字符和空格。
有关变量的更多信息（包括示例），请参阅[在工作流中使用变量](workflows-working-with-variables.md)。
对应的 UI：“输入”选项卡/**变量 – 可选**
## Outputs
(*action-name*/**Outputs**)
（可选）
定义在工作流运行期间操作输出的数据。
对应的 UI：**输出**选项卡
## Artifacts - output
(*action-name*/Outputs/**Artifacts**)
（可选）
指定操作生成的构件的名称。构件名称在工作流内必须是唯一的，并且仅限于字母数字字符（a-z、A-Z、0-9）和下划线（\$1）。不允许使用空格、连字符（-）和特殊字符。不能使用引号以使输出构件名称包含空格、连字符和其他特殊字符。
有关构件的更多信息（包括示例），请参阅[在操作之间共享构件和文件](workflows-working-artifacts.md)。
对应的 UI：“输出”选项卡/**构件**
## Name
(*action-name*/Outputs/Artifacts/**Name**)
（如果包含 [Artifacts - output](#github.outputs.artifacts)，则为必需）
指定操作生成的构件的名称。构件名称在工作流内必须是唯一的，并且仅限于字母数字字符（a-z、A-Z、0-9）和下划线（\$1）。不允许使用空格、连字符（-）和特殊字符。不能使用引号以使输出构件名称包含空格、连字符和其他特殊字符。
有关构件的更多信息（包括示例），请参阅[在操作之间共享构件和文件](workflows-working-artifacts.md)。
**对应的用户界面：输出tab/Artifacts/Add构件/构建构件名称**
## Files
(*action-name*/Outputs/Artifacts/**Files**)
（如果包含 [Artifacts - output](#github.outputs.artifacts)，则为必需）
指定由操作输出的构件中 CodeCatalyst 包含的文件。这些文件由工作流操作在运行时生成，也可在您的源存储库中找到。文件路径可以位于源存储库或先前操作的构件中，并且相对于源存储库或构件根目录。您可以使用 glob 模式来指定路径。示例：
+ 要指定位于构建位置或源存储库位置根目录中的单个文件，请使用 `my-file.jar`。
+ 要在子目录中指定单个文件，请使用 `directory/my-file.jar` 或 `directory/subdirectory/my-file.jar`。
+ 要指定所有文件，请使用 `"**/*"`。`**` glob 模式表示匹配任意数量的子目录。
+ 要指定名为 `directory` 的目录中的所有文件和目录，请使用 `"directory/**/*"`。`**` glob 模式表示匹配任意数量的子目录。
+ 要指定名为 `directory` 的目录中的所有文件，而非其任意子目录，请使用 `"directory/*"`。
**注意**
如果您的文件路径包含一个或多个星号（`*`）或其他特殊字符，请用双引号（`""`）将路径括起来。有关特殊字符的更多信息，请参阅[语法准则和惯例](workflow-reference.md#workflow.terms.syntax.conv)。
有关构件的更多信息（包括示例），请参阅[在操作之间共享构件和文件](workflows-working-artifacts.md)。
**注意**
您可能需要在文件路径中添加前缀，以指明要在哪个构件或源中查找它。有关更多信息，请参阅[引用源存储库文件](workflows-sources-reference-files.md)和[在构件中引用文件](workflows-working-artifacts-refer-files.md)。
相应的 UI：输出tab/Artifacts/Add构件/编译生成的**文件**
## Variables - output
(*action-name*/Outputs/**Variables**)
（可选）
指定希望操作导出的变量，以便后续操作可以使用这些变量。
有关变量的更多信息（包括示例），请参阅[在工作流中使用变量](workflows-working-with-variables.md)。
对应的 UI：“输出”选项卡/变量/**添加变量**
## variable-name-1
（*action-name*/Outputs/Variables**变量名称-1**）
（可选）
指定希望操作导出的变量的名称。此变量必须已在同一操作的 `Inputs` 或 `Steps` 部分中定义。
有关变量的更多信息（包括示例），请参阅[在工作流中使用变量](workflows-working-with-variables.md)。
**对应的用户界面：输出tab/Variables/Add变量/名称**
## AutoDiscoverReports
(*action-name*/Outputs/**AutoDiscoverReports**)
（可选）
定义自动发现功能的配置。
启用自动发现后，会 CodeCatalyst 搜索操作中`Inputs`传递的所有文件以及操作本身生成的所有文件，以查找测试、代码覆盖率和软件组合分析 (SCA) 报告。对于找到的每个报告，将其 CodeCatalyst 转换为 CodeCatalyst 报告。*CodeCatalyst 报告*是完全集成到 CodeCatalyst 服务中的报告，可以通过 CodeCatalyst 控制台查看和操作。
**注意**
默认情况下，自动发现功能会检查所有文件。您可以使用 [IncludePaths](#github.reports.includepaths) 或 [ExcludePaths](#github.reports.excludepaths) 属性限制检查哪些文件。
对应的 UI：*无*
## Enabled
(*action-name*/Outputs/AutoDiscoverReports/**Enabled**)
（可选）
启用或禁用自动发现功能。
有效值为 `true` 或 `false`。
如果省略 `Enabled`，则默认值为 `true`。
对应的 UI：“输出”选项卡/报告/**自动发现报告**
## ReportNamePrefix
(*action-name*/Outputs/AutoDiscoverReports/**ReportNamePrefix**)
（如果包含并启用 [AutoDiscoverReports](#github.outputs.autodiscover)，则为必需）
为其找到的所有报告指定一个前缀，以便命名其关联 CodeCatalyst 的报告。 CodeCatalyst 例如，如果您将前缀指定为`AutoDiscovered`，并 CodeCatalyst自动发现两个测试报告`TestSuiteTwo.xml`，`TestSuiteOne.xml`则关联 CodeCatalyst 的报告将命名为 `AutoDiscoveredTestSuiteOne` and。`AutoDiscoveredTestSuiteTwo`
相应的 UI：输出tab/Reports/Automatically发现报告/ **报告**前缀
## IncludePaths
(*action-name*/Outputs/AutoDiscoverReports/**IncludePaths**)
Or
(*action-name*/Outputs/Reports/*report-name-1*/**IncludePaths**)
（如果包含并启用 [AutoDiscoverReports](#github.outputs.autodiscover)，或者包含 [Reports](#github.configuration.reports)，则为必需）
指定搜索原始报告时 CodeCatalyst 包含的文件和文件路径。例如，如果您指定`"/test/report/*"`，则会在操作使用的整个[构建映像](build-images.md)中 CodeCatalyst 搜索该`/test/report/*`目录。当它找到该目录时， CodeCatalyst 然后在该目录中查找报告。
**注意**
如果您的文件路径包含一个或多个星号（`*`）或其他特殊字符，请用双引号（`""`）将路径括起来。有关特殊字符的更多信息，请参阅[语法准则和惯例](workflow-reference.md#workflow.terms.syntax.conv)。
如果省略此属性，则默认值为 `"**/*"`，这意味着搜索范围包括所有路径的所有文件。
**注意**
对于手动配置的报告，`IncludePaths` 必须是与单个文件匹配的 glob 模式。
对应的 UI：
+ **输出tab/Reports/Automatically discover reports/'Include/exclude路径'/包括路径**
+ **输出tab/Reports/Manually配置报告/ *report-name-1* /'包含/排除路径'/包含路径**
## ExcludePaths
(*action-name*/Outputs/AutoDiscoverReports/**ExcludePaths**)
Or
(*action-name*/Outputs/Reports/*report-name-1*/**ExcludePaths**)
（可选）
指定搜索原始报告时 CodeCatalyst 排除的文件和文件路径。例如，如果您指定`"/test/my-reports/**/*"`，则 CodeCatalyst 不会在`/test/my-reports/`目录中搜索文件。要忽略某个目录中的所有文件，请使用 `**/*` glob 模式。
**注意**
如果您的文件路径包含一个或多个星号（`*`）或其他特殊字符，请用双引号（`""`）将路径括起来。有关特殊字符的更多信息，请参阅[语法准则和惯例](workflow-reference.md#workflow.terms.syntax.conv)。
对应的 UI：
+ **输出tab/Reports/Automatically discover reports/'Include/exclude路径'/排除路径**
+ **输出tab/Reports/Manually配置报告/ *report-name-1* /'包含/排除路径'/排除路径**
## SuccessCriteria
(*action-name*/Outputs/AutoDiscoverReports/**SuccessCriteria**)
Or
(*action-name*/Outputs/Reports/*report-name-1*/**SuccessCriteria**)
（可选）
为测试、代码覆盖率、软件组成分析（SCA）和静态分析（SA）报告指定成功标准。
有关更多信息，请参阅 [配置报告的成功标准](test-config-action.md#test.success-criteria)。
对应的 UI：
+ 产出tab/Reports/Automatically发现报告/ **成功标准**
+ 输出tab/Reports/Manually配置报告/*report-name-1*/**成功标准**
## PassRate
(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**PassRate**)
Or
(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**PassRate**)
（可选）
指定测试报告中必须通过测试的百分比，关联 CodeCatalyst的报告才会被标记为通过。有效值包括十进制数字。例如：`50`、`60.5`。通过率标准仅适用于测试报告。有关测试报告的更多信息，请参阅[测试报告](test-workflow-actions.md#test-reports)。
对应的 UI：
+ **输出tab/Reports/Automatically discover reports/Success标准/通过率**
+ **输出tab/Reports/Manually配置报告 *report-name-1* //成功标准/通过率**
## LineCoverage
(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**LineCoverage**)
Or
(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**LineCoverage**)
（可选）
指定代码覆盖率报告中必须覆盖的行数百分比，关联 CodeCatalyst 的报告才会被标记为通过。有效值包括十进制数字。例如：`50`、`60.5`。行覆盖率标准仅适用于代码覆盖率报告。有关代码覆盖率报告的更多信息，请参阅[代码覆盖率报告](test-workflow-actions.md#test-code-coverage-reports)。
对应的 UI：
+ **输出tab/Reports/Automatically discover reports/Success标准/线路覆盖范围**
+ **输出tab/Reports/Manually配置报告 *report-name-1* //成功标准/线路覆盖率**
## BranchCoverage
(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**BranchCoverage**)
Or
(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**BranchCoverage**)
（可选）
指定代码覆盖率报告中必须覆盖的分支百分比才能将关联 CodeCatalyst 报告标记为已通过。有效值包括十进制数字。例如：`50`、`60.5`。分支覆盖率标准仅适用于代码覆盖率报告。有关代码覆盖率报告的更多信息，请参阅[代码覆盖率报告](test-workflow-actions.md#test-code-coverage-reports)。
对应的 UI：
+ **产出tab/Reports/Automatically discover reports/Success标准/分支机构覆盖范围**
+ **输出tab/Reports/Manually配置报告 *report-name-1* //成功标准/分支覆盖范围**
## Vulnerabilities
(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**Vulnerabilities**)
Or
(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**Vulnerabilities**)
（可选）
指定 SCA 报告中允许将关联 CodeCatalyst 报告标记为已通过的最大漏洞数量和严重性。要指定漏洞，您必须指定：
+ 要计入的漏洞的最低严重性。有效值（按严重程度从高到低）为 `CRITICAL`、`HIGH`、`MEDIUM`、`LOW` 和 `INFORMATIONAL`。
例如，如果您选择 `HIGH`，则将计算 `HIGH` 和 `CRITICAL` 漏洞的总数。
+ 您希望允许的具有指定严重性的漏洞的最大数量。超过此数字会导致 CodeCatalyst 报告被标记为失败。有效值为整数。
漏洞标准仅适用于 SCA 报告。有关 SCA 报告的更多信息，请参阅[软件组成分析报告](test-workflow-actions.md#test-sca-reports)。
要指定最低严重性，请使用 `Severity` 属性。要指定最大漏洞数，请使用 `Number` 属性。
有关 SCA 报告的更多信息，请参阅[质量报告类型](test-workflow-actions.md#test-reporting)。
对应的 UI：
+ **输出tab/Reports/Automatically discover reports/Success标准/漏洞**
+ **输出tab/Reports/Manually配置报告 *report-name-1* //成功标准/漏洞**
## Reports
(*action-name*/Outputs/**Reports** )
（可选）
一个部分，用于指定测试报告的配置。
对应的 UI：“输出”选项卡/**报告**
## report-name-1
（*action-name*/Outputs/Reports/**报告名称 1）**
（如果包含 [Reports](#github.configuration.reports)，则为必需）
您要为将从原始 CodeCatalyst 报告生成的报告命名。
相应的 UI：输出tab/Reports/Manually配置报告/ **报告名称**
## Format
(*action-name*/Outputs/Reports/*report-name-1*/**Format**)
（如果包含 [Reports](#github.configuration.reports)，则为必需）
指定您用于报告的文件格式。可能值如下所示。
+ 对于测试报告：
+ 对于 Cucumber JSON，请指定 **Cucumber**（可视化编辑器）或 `CUCUMBERJSON`（YAML 编辑器）。
+ 对于 JUnit XML，请指定 **JUnit**（可视化编辑器）或`JUNITXML`（YAML 编辑器）。
+ 对于 NUnit XML，请指定 **NUnit**（可视化编辑器）或`NUNITXML`（YAML 编辑器）。
+ 对于 NUnit 3 XML，请指定 **NUnit3**（可视化编辑器）或`NUNIT3XML`（YAML 编辑器）。
+ 对于 Visual Studio TRX，请指定 **Visual Studio TRX**（可视化编辑器）或 `VISUALSTUDIOTRX`（YAML 编辑器）。
+ 对于 TestNG XML，请指定 **TestNG**（可视化编辑器）或 `TESTNGXML`（YAML 编辑器）。
+ 对于代码覆盖率报告：
+ 对于 Clover XML，请指定 **Clover**（可视化编辑器）或 `CLOVERXML`（YAML 编辑器）。
+ 对于 Cobertura XML，请指定 **Cobertura**（可视化编辑器）或 `COBERTURAXML`（YAML 编辑器）。
+ 对于 JaCoCo XML，请指定 **JaCoCo**（可视化编辑器）或`JACOCOXML`（YAML 编辑器）。
+ 对于由 s [implecov](https://github.com/simplecov-ruby/simplecov) 生成的 SimpleCov JSON，而不是 s [implecov-json](https://github.com/vicentllongo/simplecov-json)，请指定 S **implecov（可视化编辑器）或**（YAML 编辑器）。`SIMPLECOV`
+ 对于软件组成分析（SCA）报告：
+ 对于 SARIF，请指定 **SARIF**（可视化编辑器）或 `SARIFSCA`（YAML 编辑器）。
对应的用户界面：输出tab/Reports/Manually configure reports/Add报告*report-name-1*//**报告类型**和**报告格式**
## Configuration
(*action-name*/**Configuration**)
（必需）可在其中定义操作的配置属性的部分。
对应的 UI：**配置**选项卡
## Steps
(*action-name*/Configuration/**Steps**)
（必需）
在 GitHub M [GitHub arketplac](https://github.com/marketplace) e 中指定操作详情页面上显示的操作代码。按照以下指南来添加代码：
1. 将 “ GitHub 操作`steps:`” 部分中的代码粘贴到 CodeCatalyst 工作流程的`Steps:`部分中。该代码以短划线（-）开头，与以下内容类似。
GitHub 要粘贴的代码：
```
- name: Lint Code Base
uses: github/super-linter@v4
env:
VALIDATE_ALL_CODEBASE: false
DEFAULT_BRANCH: master
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
```
1. 查看您刚刚粘贴的代码，并在必要时对其进行修改，使其符合标准。 CodeCatalyst例如，在前面的代码块中，您可以删除中的代码*red italics*，然后添加**粗体**代码。
CodeCatalyst 工作流程 yaml：
```
Steps:
- name: Lint Code Base
uses: github/super-linter@v4
env:
VALIDATE_ALL_CODEBASE: false
DEFAULT_BRANCH: mastermain
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
```
1. 对于 GitHub 操作中包含但该`steps:`部分中不存在的其他代码，请使用 CodeCatalyst等效代码将其添加到 CodeCatalyst 工作流程中。您可以查看，[工作流 YAML 定义](workflow-reference.md)以深入了解如何将 GitHub 代码移植到 CodeCatalyst。详细的迁移步骤不在本指南的讨论范围内。
以下是如何在 “**GitHub 操作**” 操作中指定文件路径的示例：
```
Steps:
- name: Lint Code Base
uses: github/super-linter@v4
...
- run: cd /sources/WorkflowSource/MyFolder/ && cat file.txt
- run: cd /artifacts/MyGitHubAction/MyArtifact/MyFolder/ && cat file2.txt
```
有关指定文件路径的更多信息，请参阅[引用源存储库文件](workflows-sources-reference-files.md)和[在构件中引用文件](workflows-working-artifacts-refer-files.md)。
对应的用户界面：“配置” 选项卡/ **GitHub 操作 YAML**