亚马逊 CodeCatalyst 不再向新买家开放。现有客户可以继续正常使用该服务。有关更多信息，请参阅 [如何从中迁移 CodeCatalyst](migration.md)。 本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 配置工作流操作 *操作*是工作流的主要构建基块，它定义了工作流运行期间要执行的逻辑工作单元（又称任务）。通常，一个工作流包括多个按顺序运行或并行运行的操作，具体取决于您配置这些操作的方式。 **Topics** + [操作类型](#workflows-actions-types) + [添加操作到工作流](workflows-add-action.md) + [从工作流中删除操作](workflows-delete-action.md) + [开发自定义操作](workflows-custom-action.md) + [将操作分组为操作组](workflows-group-actions.md) + [顺序操作](workflows-depends-on.md) + [在操作之间共享构件和文件](workflows-working-artifacts.md) + [指定要使用的操作版本](workflows-action-versions.md) + [列出可用的操作版本](workflows-action-versions-determine.md) + [查看操作的源代码](workflows-view-source.md) + [与 GitHub 操作集成](integrations-github-actions.md) ## 操作类型 在 Amazon CodeCatalyst 工作流程中，您可以使用以下类型的操作。 **Topics** + [CodeCatalyst 行动](#workflows-actions-types-cc) + [CodeCatalyst 实验室行动](#workflows-actions-types-cc-labs) + [GitHub 行动](#workflows-actions-types-github) + [第三方操作](#workflows-actions-types-3p) ### CodeCatalyst 行动 *CodeCatalyst 动*作是由 CodeCatalyst 开发团队创作、维护和全力支持的动作。 有一些用于构建、测试和部署应用程序的 CodeCatalyst 操作，以及用于执行其他任务（例如调用 AWS Lambda 函数）的操作。 以下 CodeCatalyst 操作可用： + **构建** 此操作会构建您的构件并在 Docker 容器中运行单元测试。有关更多信息，请参阅 [添加构建操作](build-add-action.md)。 + **测试** 此操作会针对您的应用程序或构件运行集成和系统测试。有关更多信息，请参阅 [添加测试操作](test-add-action.md)。 + **Amazon S3 发布** 此操作会将应用程序构件复制到 Amazon S3 存储桶。有关更多信息，请参阅 [使用工作流将文件发布到 Amazon S3](s3-pub-action.md)。 + **AWS CDK bootstrap** 此操作会预置部署 CDK 应用程序 AWS CDK 所需的资源。有关更多信息，请参阅 [使用工作流程引导 AWS CDK 应用程序](cdk-boot-action.md)。 + **AWS CDK 部署** 此操作合成并部署应用程序。 AWS Cloud Development Kit (AWS CDK) 有关更多信息，请参阅 [使用工作流程部署 AWS CDK 应用程序](cdk-dep-action.md)。 + **AWS Lambda 调用** 此操作调用一个函数。 AWS Lambda 有关更多信息，请参阅 [使用工作流调用 Lambda 函数](lam-invoke-action.md)。 + **GitHub 操作** 此操作允许您在 CodeCatalyst 工作流程中运行 GitHub 操作。*CodeCatalyst*有关更多信息，请参阅 [使用工作流调用 Lambda 函数](lam-invoke-action.md)。 + **部署 CloudFormation 堆栈** 此操作会部署 CloudFormation 堆栈。有关更多信息，请参阅 [部署 CloudFormation 堆栈](deploy-action-cfn.md)。 + **部署到 Amazon ECS** 此操作会注册 Amazon ECS 任务定义并将其部署到 Amazon ECS 服务。有关更多信息，请参阅 [使用工作流部署到 Amazon ECS](deploy-action-ecs.md)。 + **部署到 Kubernetes 集群** 此操作会将应用程序部署到 Kubernetes 集群。有关更多信息，请参阅 [使用工作流部署到 Amazon EKS](deploy-action-eks.md)。 + **渲染 Amazon ECS 任务定义** 此操作会将容器映像 URI 插入到 Amazon ECS 任务定义 JSON 文件中，从而创建新的任务定义文件。有关更多信息，请参阅 [修改 Amazon ECS 任务定义](render-ecs-action.md)。 CodeCatalyst 操作文档可在本指南和每个操作的自述文件中找到。 有关可用 CodeCatalyst 操作以及如何向工作流程添加操作的信息，请参阅[添加操作到工作流](workflows-add-action.md)。 ### CodeCatalyst 实验室行动 *CodeCatalyst 实验室操作*是 Amazon Labs 的一部分，Amazon CodeCatalyst Labs 是实验性应用程序的试验场。 CodeCatalyst 已经开发了实验室操作来展示与 AWS 服务的集成。 以下 CodeCatalyst 实验室操作可用： + **部署到 AWS Amplify 主机** 该操作会将应用程序部署到 Amplify Hosting。 + **部署到 AWS App Runner** 此操作会将源映像存储库中的最新映像部署到 App Runner。 + **部署到亚马逊 CloudFront 和亚马逊 S3** 此操作会将应用程序部署到 CloudFront 和 Amazon S3。 + **使用部署 AWS SAM** 此操作使用 AWS Serverless Application Model （AWS SAM）部署无服务器应用程序。 + **使 Amazon CloudFront 缓存失效** 此操作会使给定路径集的 CloudFront 缓存失效。 + **传出 Webhook** 此操作使用户能够使用 HTTPS 请求将工作流中的消息发送到任意 Web 服务器。 + **发布到 AWS CodeArtifact** 此操作将包发布到 CodeArtifact 存储库。 + **发布到 Amazon SNS** 此操作使用户能够通过创建主题、发布到主题或订阅主题来与 Amazon SNS 集成。 + **推送到 Amazon ECR** 此操作会构建 Docker 映像并将其发布到 Amazon Elastic Container Registry（Amazon ECR）存储库。 + **使用 Amazon CodeGuru 安全软件进行扫描** 此操作会创建已配置代码路径的 zip 存档，并使用 “ CodeGuru 安全” 来运行代码扫描。 + **Terraform Community Edition** 此操作会运行 Terraform Community Edition 的 `plan` 和 `apply` 操作。 CodeCatalyst 实验室操作的文档可在每个操作的自述文件中找到。 有关向工作流程添加 CodeCatalyst 实验室操作和查看其自述文件的信息，请参阅[添加操作到工作流](workflows-add-action.md)。 ### GitHub 行动 Acti *GitHub on* 很像一个[CodeCatalyst 动作](#workflows-actions-types-cc)，不同之处在于它是为与 GitHub 工作流程一起使用而开发的。有关 GitHub 操作的详细信息，请参阅[GitHub 操作](https://docs.github.com/en/actions)文档。 在 CodeCatalyst 工作流程中，您可以将 GitHub CodeCatalyst 操作与原生操作一起使用。 为方便起见， CodeCatalyst 控制台提供了对多个常用 GitHub操作的访问权限。您也可以使用 [GitHub Marketplace](https://github.com/marketplace/actions) 中列出的任何 GitHub 操作（但有一些限制）。 操作文档可在每个 GitHub 操作的自述文件中找到。 有关更多信息，请参阅 [与 GitHub 操作集成](integrations-github-actions.md)。 ### 第三方操作 *第三方操作*是由第三方供应商创作并在 CodeCatalyst 控制台中提供的操作。第三方操作的示例包括分别由 **Mend 和 Sonar 编写的 “修复 SCA**” 和 “**SonarCloud 扫描**” 操作。 第三方操作的文档可在每个操作的自述文件中找到。第三方供应商也可能提供其它文档。 有关向工作流中添加第三方操作和查看操作自述文件的信息，请参阅[添加操作到工作流](workflows-add-action.md)。 # 添加操作到工作流 按照以下说明向工作流添加操作，然后进行配置。 **添加和配置操作** 1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 1. 选择您的项目。 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择工作流的名称。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。 1. 选择**编辑**。 1. 在左上角，选择 **\$1 操作**后将显示**操作**目录。 1. 在下拉列表中，执行以下操作之一： + 选择 **Amazon CodeCatalyst** 进行查看[CodeCatalyst](workflows-actions.md#workflows-actions-types-cc)、选择[CodeCatalyst 实验室](workflows-actions.md#workflows-actions-types-cc-labs)或[第三方](workflows-actions.md#workflows-actions-types-3p)操作。 + CodeCatalyst 动作有 b **y AWS** 标签。 + CodeCatalyst 实验室操作带有 “**按 CodeCatalyst 实验室**” 标签。 + 第三方操作有 b **y *vendor*** 标签，其中*vendor*是第三方供应商的名称。 + 选择**GitHub**查看[精选的 GitHub 操作列表。](integrations-github-action-add-curated.md) 1. 在操作目录中，搜索操作，然后执行以下操作之一： + 选择加号（**\$1**）可将操作添加到您的工作流中。 + 选择操作的名称以查看其自述文件。 1. 配置操作。选择**可视化**以使用可视化编辑器，或者选择 **YAML** 以使用 YAML 编辑器。有关详细说明，请参阅以下链接。 有关添加[CodeCatalyst操作](workflows-actions.md#workflows-actions-types-cc)的说明，请参阅： + [添加构建操作](build-add-action.md) + [添加测试操作](test-add-action.md) + [添加“部署到 Amazon ECS”操作](deploy-action-ecs-adding.md) + [添加“部署到 Kubernetes 集群”操作](deploy-action-eks-adding.md) + [添加 “部署 CloudFormation 堆栈” 操作](deploy-action-cfn-adding.md) + [添加 “AWS CDK 部署” 操作](cdk-dep-action-add.md) + [添加 “AWS CDK 引导” 操作](cdk-boot-action-add.md) + [添加“Amazon S3 发布”操作](s3-pub-action-add.md) + [添加 “AWS Lambda 调用” 操作](lam-invoke-action-add.md) + [添加“渲染 Amazon ECS 任务定义”操作](render-ecs-action-add.md) 有关添加[CodeCatalyst 实验室操作](workflows-actions.md#workflows-actions-types-cc-labs)的说明，请参阅： + 操作的自述文件。您可以通过在操作目录中选择操作名称来找到自述文件。 有关添加[GitHub 操作](workflows-actions.md#workflows-actions-types-github)的说明，请参阅： + [与 GitHub 操作集成](integrations-github-actions.md) 有关添加[第三方操作](workflows-actions.md#workflows-actions-types-3p)的说明，请参阅： + 操作的自述文件。您可以通过在操作目录中选择操作名称来找到自述文件。 1. （可选）选择**验证**以确保 YAML 代码有效。 1. 选择**提交**以提交您的更改。 # 从工作流中删除操作 按照以下说明从工作流中删除操作。 ------ #### [ Visual ] **使用可视化编辑器删除操作** 1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 1. 选择您的项目。 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择工作流的名称。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。 1. 选择**编辑**。 1. 选择**可视化**。 1. 在工作流图表中，在要删除的操作中，选择垂直省略号（![\[Ellipsis.\]](http://docs.aws.amazon.com/zh_cn/codecatalyst/latest/userguide/images/flows/elipsis.png)）图标，然后选择**删除**。 1. （可选）选择**验证**，在提交之前验证工作流的 YAML 代码。 1. 选择**提交**，输入提交消息，然后再次选择**提交**。 ------ #### [ YAML ] **使用 YAML 编辑器删除操作** 1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 1. 选择您的项目。 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择工作流的名称。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。 1. 选择**编辑**。 1. 选择 **YAML**。 1. 找到 YAML 中包含要删除的操作的部分。 选择该部分并按键盘上的 Delete 键。 1. （可选）选择**验证**，在提交之前验证工作流的 YAML 代码。 1. 选择**提交**，输入提交消息，然后再次选择**提交**。 ------ # 开发自定义操作 您可以使用动作开发套件 (ADK) 开发自定义 CodeCatalyst 操作以在工作流程中使用。然后，您可以将该操作发布到 CodeCatalyst 操作目录，以便其他 CodeCatalyst 用户可以在其工作流程中查看和使用它。 **开发、测试和发布操作（高级任务）** 1. 安装开发操作所需的工具和程序包。 1. 创建 CodeCatalyst 存储库来存储您的操作代码。 1. 初始化操作。这会列出操作所需的源文件，包括您可以用自己的代码更新的操作定义文件（`action.yml`）。 1. 引导操作代码以获取构建、测试和发布操作项目所需的工具和库。 1. 在本地计算机上生成操作，然后将更改推送到存储 CodeCatalyst库。 1. 在本地使用单元测试测试操作，然后在中运行 ADK 生成的工作流程。 CodeCatalyst 1. 在 CodeCatalyst 控制台中选择 “**发布” 按钮，将 CodeCatalyst 操作发布**到操作目录。 有关详细步骤，请参阅 [Amazon Acti CodeCatalyst on 开发套件开发者指南](https://docs.aws.amazon.com/codecatalyst/latest/adk/what-is-action-development-kit.html)。 # 将操作分组为操作组 一个*操作组*包含一个或多个操作。将操作分组为操作组有助于将工作流保持得井井有条，还可以配置不同组之间的依赖关系。 **注意** 您不能将操作组嵌套到其他操作组或操作中。 **Topics** + [定义操作组](#workflows-define-action-group) + [示例：定义两个操作组](workflows-group-actions-example.md) ## 定义操作组 按照以下说明定义 CodeCatalyst 操作组。 ------ #### [ Visual ] *不可用。选择 YAML 以查看 YAML 说明。* ------ #### [ YAML ] **定义组** 1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 1. 选择您的项目。 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择工作流的名称。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。 1. 选择**编辑**。 1. 选择 **YAML**。 1. 在 `Actions` 中，添加类似于以下代码的代码： ``` Actions: action-group-name: Actions: action-1: Identifier: aws/build@v1 Configuration: ... action-2: Identifier: aws/build@v1 Configuration: ... ``` 有关另一个示例，请参阅[示例：定义两个操作组](workflows-group-actions-example.md)。有关更多信息，请参阅[工作流 YAML 定义](workflow-reference.md)的[操作](workflow-reference.md#actions-reference)中对 `action-group-name` 属性的说明。 1. （可选）选择**验证**，在提交之前验证工作流的 YAML 代码。 1. 选择**提交**，输入提交消息，然后再次选择**提交**。 ------ # 示例：定义两个操作组 以下示例说明如何定义两个 Amazon CodeCatalyst 操作组：`BuildAndTest`和`Deploy`。`BuildAndTest` 组包括两个操作（`Build` 和 `Test`），`Deploy` 组同样包括两个操作（`DeployCloudFormationStack` 和 `DeployToECS`）。 ``` Actions: BuildAndTest: # Action group 1 Actions: Build: Identifier: aws/build@v1 Configuration: ... Test: Identifier: aws/managed-test@v1 Configuration: Deploy: #Action group 2 Actions: DeployCloudFormationStack: Identifier: aws/cfn-deploy@v1 Configuration: ... DeployToECS: Identifier: aws/ecs-deploy@v1 Configuration: ... ``` # 顺序操作 默认情况下，当您将操作添加到工作流时，它们将并排添加到[可视化编辑器](workflow.md#workflow.editors)中。这意味着，当您启动工作流运行时，这些操作将并行运行。如果要让操作按顺序运行（并垂直显示在可视化编辑器中），您必须设置它们之间的依赖关系。例如，您可以将 `Test` 操作设置为依赖于 `Build` 操作，这样就让测试操作在构建操作之后运行。 您可以在操作和操作组之间设置依赖关系。您还可以配置 one-to-many依赖关系，以便一个操作依赖于其他几个操作才能启动。请查阅[设置操作之间的依赖关系](workflows-depends-on-set-up.md)中的准则，确保您的依赖项设置符合工作流的 YAML 语法。 **Topics** + [如何在操作之间配置依赖关系的示例](workflows-depends-on-examples.md) + [设置操作之间的依赖关系](workflows-depends-on-set-up.md) # 如何在操作之间配置依赖关系的示例 以下示例说明如何在工作流定义文件中，配置操作和组之间的依赖关系。 **Topics** + [示例：配置简单依赖关系](#workflows-depends-on-example-simple) + [示例：将操作组配置为依赖于操作](#workflows-depends-on-example-action-groups-actions) + [示例：将一个操作组配置为依赖于另一个操作组](#workflows-depends-on-example-two-action-groups) + [示例：将操作组配置为依赖于多个操作](#workflows-depends-on-example-advanced) ## 示例：配置简单依赖关系 以下示例说明如何使用 `DependsOn` 属性将 `Test` 操作配置为依赖于 `Build` 操作。 ``` Actions: Build: Identifier: aws/build@v1 Configuration: ... Test: DependsOn: - Build Identifier: aws/managed-test@v1 Configuration: ... ``` ## 示例：将操作组配置为依赖于操作 以下示例说明如何将 `DeployGroup` 操作组配置为依赖于 `FirstAction` 操作。请注意，操作和操作组处于同一级别。 ``` Actions: FirstAction: #An action outside an action group Identifier: aws/github-actions-runner@v1 Configuration: ... DeployGroup: #An action group containing two actions DependsOn: - FirstAction Actions: DeployAction1: ... DeployAction2: ... ``` ## 示例：将一个操作组配置为依赖于另一个操作组 以下示例说明如何将 `DeployGroup` 操作组配置为依赖于 `BuildAndTestGroup` 操作组。请注意，这些操作组处于同一级别。 ``` Actions: BuildAndTestGroup: # Action group 1 Actions: BuildAction: ... TestAction: ... DeployGroup: #Action group 2 DependsOn: - BuildAndTestGroup Actions: DeployAction1: ... DeployAction2: ... ``` ## 示例：将操作组配置为依赖于多个操作 以下示例说明如何将 `DeployGroup` 操作组配置为依赖于 `FirstAction` 操作、`SecondAction` 操作和 `BuildAndTestGroup` 操作组。请注意，`DeployGroup` 与 `FirstAction`、`SecondAction` 和 `BuildAndTestGroup` 处于同一级别。 ``` Actions: FirstAction: #An action outside an action group ... SecondAction: #Another action ... BuildAndTestGroup: #Action group 1 Actions: Build: ... Test: ... DeployGroup: #Action group 2 DependsOn: - FirstAction - SecondAction - BuildAndTestGroup Actions: DeployAction1: ... DeployAction2: ... ``` # 设置操作之间的依赖关系 按照以下说明设置工作流中操作之间的依赖关系。 配置依赖关系时，请按照以下准则操作： + 如果某个操作位于组中，则该操作只能依赖于同一组中的其他操作。 + 操作和操作组可以依赖于 YAML 层次结构中*同一级别*的其他操作和操作组，但*不能*依赖于其他级别中的操作和操作组。 ------ #### [ Visual ] **使用可视化编辑器设置依赖关系** 1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 1. 选择您的项目。 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择工作流的名称。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。 1. 选择**编辑**。 1. 选择**可视化**。 1. 在工作流图表中，选择将依赖于其他操作的操作。 1. 选择**输入**选项卡。 1. 在**依赖于 – 可选**中，执行以下操作： 指定必须成功运行才能使该操作运行的操作、操作组或阶段门。 有关“依赖于”功能的更多信息，请参阅[顺序操作](workflows-depends-on.md)。 1. （可选）选择**验证**，在提交之前验证工作流的 YAML 代码。 1. 选择**提交**，输入提交消息，然后再次选择**提交**。 ------ #### [ YAML ] **使用 YAML 编辑器设置依赖关系** 1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 1. 选择您的项目。 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择工作流的名称。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。 1. 选择**编辑**。 1. 选择 **YAML**。 1. 在依赖于另一个操作的操作中，添加类似于下文的代码： ``` action-name: DependsOn: - action-1 ``` 有关更多示例，请参阅[如何在操作之间配置依赖关系的示例](workflows-depends-on-examples.md)。有关一般准则，请参阅[设置操作之间的依赖关系](#workflows-depends-on-set-up)。有关更多信息，请参阅[工作流 YAML 定义](workflow-reference.md) 中相应操作 `DependsOn` 属性的说明。 1. （可选）选择**验证**，在提交之前验证工作流的 YAML 代码。 1. 选择**提交**，输入提交消息，然后再次选择**提交**。 ------ # 在操作之间共享构件和文件 *构件*是工作流操作的输出，通常由文件夹或文件存档组成。构件之所以重要，是因为它们让您可以在操作之间共享文件和信息。 例如，您可能有一个构建操作*生成*了 `sam-template.yml` 文件，但您希望部署操作*使用*该文件。在这种情况下，您将使用构件来允许构建操作与部署操作共享 `sam-template.yml` 文件。代码类似于如下所示： ``` Actions: BuildAction: Identifier: aws/build@v1 Steps: - Run: sam package --output-template-file sam-template.yml Outputs: Artifacts: - Name: MYARTIFACT Files: - sam-template.yml DeployAction: Identifier: aws/cfn-deploy@v1 Inputs: Artifacts: - MYARTIFACT Configuration: template: sam-template.yml ``` 在前面的代码中，构建操作（`BuildAction`）生成一个 `sam-template.yml` 文件，然后将其添加到名为 `MYARTIFACT` 的输出构件中。随后的部署操作（`DeployAction`）指定 `MYARTIFACT` 作为输入，向其提供了对 `sam-template.yml` 文件的访问权限。 **Topics** + [我能否在不将构件指定为输出和输入的情况下共享它们？](#workflows-working-artifacts-share) + [我能否在工作流之间共享构件？](#workflows-working-artifacts-share-wf) + [构件示例](workflows-working-artifacts-ex.md) + [定义输出构件](workflows-working-artifacts-output.md) + [定义输入构件](workflows-working-artifacts-refer.md) + [在构件中引用文件](workflows-working-artifacts-refer-files.md) + [下载构件](workflows-download-workflow-outputs.md) ## 我能否在不将构件指定为输出和输入的情况下共享它们？ 可以，您可以在操作之间共享构件，而无需在操作的 YAML 代码的 `Outputs` 和 `Inputs` 部分中指定构件。为此，您必须启用计算共享。有关计算共享以及如何在启用计算共享时指定构件的更多信息，请参阅[跨操作共享计算](compute-sharing.md)。 **注意** 尽管计算共享功能通过消除对 `Outputs` 和 `Inputs` 部分的需求来简化工作流的 YAML 代码，但该功能存在一些局限性，您应在启用该功能之前了解这些局限性。有关这些限制的信息，请参阅[计算共享注意事项](compute-sharing.md#compare-compute-sharing)。 ## 我能否在工作流之间共享构件？ 不可以，您不能在不同的工作流之间共享构件；但是，您可以在同一工作流中的操作之间共享构件。 # 构件示例 以下示例说明如何输出、输入和引用 Amazon CodeCatalyst 工作流程定义文件中的项目。 **Topics** + [示例：输出构件](#workflows-working-artifacts-ex-basic) + [示例：输入由其他操作生成的构件](#workflows-working-artifacts-ex-ref) + [示例：引用多个构件中的文件](#workflows-working-artifacts-ex-ref-file) + [示例：在单个构件中引用文件](#workflows-working-artifacts-ex-ref-file-one) + [示例：存在对象时引用对象中的文件 WorkflowSource](#workflows-working-artifacts-ex-ref-file-wf-source) + [示例：存在操作组时引用构件中的文件](#workflows-working-artifacts-ex-groups) ## 示例：输出构件 以下示例演示如何输出包含两个 .jar 文件的构件。 ``` Actions: Build: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ARTIFACT1 Files: - build-output/file1.jar - build-output/file2.jar ``` ## 示例：输入由其他操作生成的构件 以下示例向您展示了如何在 `BuildActionA` 中输出名为 `ARTIFACT4` 的构件并将其输入到 `BuildActionB`。 ``` Actions: BuildActionA: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ARTIFACT4 Files: - build-output/file1.jar - build-output/file2.jar BuildActionB: Identifier: aws/build@v1 Inputs: Artifacts: - ARTIFACT4 Configuration: ``` ## 示例：引用多个构件中的文件 以下示例向您展示了如何在 `BuildActionC` 中输出名为 `ART5` 和 `ART6` 的两个构件，然后在 `BuildActionD` 中（位于 `Steps` 下）引用名为 `file5.txt`（在构件 `ART5` 中）和 `file6.txt`（在构件 `ART6` 中）的两个文件。 **注意** 有关引用文件的更多信息，请参阅[在构件中引用文件](workflows-working-artifacts-refer-files.md)。 **注意** 尽管该示例显示使用了 `$CATALYST_SOURCE_DIR_ART5` 前缀，但您可以省略它。这是因为 `ART5` 是*主输入*。要了解有关主输入的更多信息，请参阅[在构件中引用文件](workflows-working-artifacts-refer-files.md)。 ``` Actions: BuildActionC: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ART5 Files: - build-output/file5.txt - Name: ART6 Files: - build-output/file6.txt BuildActionD: Identifier: aws/build@v1 Inputs: Artifacts: - ART5 - ART6 Configuration: Steps: - run: cd $CATALYST_SOURCE_DIR_ART5/build-output && cat file5.txt - run: cd $CATALYST_SOURCE_DIR_ART6/build-output && cat file6.txt ``` ## 示例：在单个构件中引用文件 以下示例向您展示了如何在 `BuildActionE` 中输出名为 `ART7` 的构件，然后在 `BuildActionF` 中（位于 `Steps` 下）引用 `file7.txt`（在构件 `ART7` 中）文件。 请注意，引用并不像在`build-output`目录前面那样需要前`$CATALYST_SOURCE_DIR_`*artifact-name*缀[示例：引用多个构件中的文件](#workflows-working-artifacts-ex-ref-file)。这是因为 `Inputs` 下仅指定了一项。 **注意** 有关引用文件的更多信息，请参阅[在构件中引用文件](workflows-working-artifacts-refer-files.md)。 ``` Actions: BuildActionE: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ART7 Files: - build-output/file7.txt BuildActionF: Identifier: aws/build@v1 Inputs: Artifacts: - ART7 Configuration: Steps: - run: cd build-output && cat file7.txt ``` ## 示例：存在对象时引用对象中的文件 WorkflowSource 以下示例向您展示了如何在 `BuildActionG` 中输出名为 `ART8` 的构件，然后在 `BuildActionH` 中（位于 `Steps` 下）引用 `file8.txt`（在构件 `ART8` 中）文件。 请注意引用是如何需要`$CATALYST_SOURCE_DIR_`*artifact-name*前缀的，就像在中一样[示例：引用多个构件中的文件](#workflows-working-artifacts-ex-ref-file)。这是因为 `Inputs` 下指定了多项（一个源和一个构件），所以您需要使用前缀来指示在哪里查找文件。 **注意** 有关引用文件的更多信息，请参阅[在构件中引用文件](workflows-working-artifacts-refer-files.md)。 ``` Actions: BuildActionG: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ART8 Files: - build-output/file8.txt BuildActionH: Identifier: aws/build@v1 Inputs: Sources: - WorkflowSource Artifacts: - ART8 Configuration: Steps: - run: cd $CATALYST_SOURCE_DIR_ART8/build-output && cat file8.txt ``` ## 示例：存在操作组时引用构件中的文件 以下示例向您展示了如何在 `ActionGroup1`、`ActionI` 中输出名为 `ART9` 的构件，然后在 `ActionJ` 中引用 `file9.txt`（在构件 `ART9` 中）。 有关引用文件的更多信息，请参阅[在构件中引用文件](workflows-working-artifacts-refer-files.md)。 ``` Actions: ActionGroup1: Actions: ActionI: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ART9 Files: - build-output/file9.yml ActionJ: Identifier: aws/cfn-deploy@v1 Inputs: Sources: - WorkflowSource Artifacts: - ART9 Configuration: template: /artifacts/ActionGroup1@ActionJ/ART9/build-output/file9.yml ``` # 定义输出构件 按照以下说明定义您希望 Amazon CodeCatalyst 操作输出的对象。该构件随后可供其他操作使用。 **注意** 并非所有操作都支持输出构件。要确定您的操作是否支持输出构件，请仔细阅读随后的可视化编辑器说明，并查看操作的**输出**选项卡上是否包含**输出构件**按钮。如果是，则支持输出构件。 ------ #### [ Visual ] **使用可视化编辑器定义输出构件** 1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 1. 选择您的项目。 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择工作流的名称。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。 1. 选择**编辑**。 1. 选择**可视化**。 1. 在工作流图表中，选择将生成构件的操作。 1. 选择**输出**选项卡。 1. 在**构件**下，选择**添加构件**。 1. 选择**添加构件**，然后在字段中输入信息，如下所示。 **生成构件名称** 指定操作生成的构件的名称。构件名称在工作流内必须是唯一的，并且仅限于字母数字字符（a-z、A-Z、0-9）和下划线（\$1）。不允许使用空格、连字符（-）和特殊字符。不能使用引号以使输出构件名称包含空格、连字符和其他特殊字符。 有关构件的更多信息（包括示例），请参阅[在操作之间共享构件和文件](workflows-working-artifacts.md)。 **通过构建生成的文件** 指定操作输出的对象中 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)。 1. （可选）选择**验证**，在提交之前验证工作流的 YAML 代码。 1. 选择**提交**，输入提交消息，然后再次选择**提交**。 ------ #### [ YAML ] **使用 YAML 编辑器定义输出构件** 1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 1. 选择您的项目。 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择工作流的名称。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。 1. 选择**编辑**。 1. 选择 **YAML**。 1. 在工作流操作中，添加类似于下文的代码： ``` action-name: Outputs: Artifacts: - Name: artifact-name Files: - file-path-1 - file-path-2 ``` 有关更多示例，请参阅[构件示例](workflows-working-artifacts-ex.md)。有关更多信息，请参阅相应操作的[工作流 YAML 定义](workflow-reference.md)。 1. （可选）选择**验证**，在提交之前验证工作流的 YAML 代码。 1. 选择**提交**，输入提交消息，然后再次选择**提交**。 ------ # 定义输入构件 如果您想使用由其他 Amazon CodeCatalyst 操作生成的项目，则必须将其指定为当前操作的输入。您可以指定多个构件作为输入，具体取决于相应操作。有关更多信息，请参阅相应操作的[工作流 YAML 定义](workflow-reference.md)。 **注意** 您不能引用其他工作流中的构件。 按照以下说明，将来自另一个操作的构件指定为当前操作的输入。 **先决条件** 在开始之前，请确保您已从其他操作输出了构件。有关更多信息，请参阅[定义输出构件](workflows-working-artifacts-output.md)。输出构件，以使其可供其他操作使用。 ------ #### [ Visual ] **将构件指定为操作的输入（可视化编辑器）** 1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 1. 选择您的项目。 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择工作流的名称。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。 1. 选择**编辑**。 1. 选择**可视化**。 1. 在工作流图表中，选择要将构件指定为输入的操作。 1. 选择**输入**。 1. 在**构件 – 可选**中，执行以下操作： 指定以前操作中的一些构件，您希望将这些构件用作此操作的输入。这些构件必须已在以前的操作中定义为输出构件。 如果未指定任何输入构件，则必须在 `action-name/Inputs/Sources` 下指定至少一个源存储库。 有关构件的更多信息（包括示例），请参阅[在操作之间共享构件和文件](workflows-working-artifacts.md)。 **注意** 如果**构件 – 可选**下拉列表不可用（可视化编辑器），或者在验证 YAML 时出现错误（YAML 编辑器），这可能是因该操作仅支持一个输入导致的。在这种情况下，请尝试移除源输入。 1. （可选）选择**验证**，在提交之前验证工作流的 YAML 代码。 1. 选择**提交**，输入提交消息，然后再次选择**提交**。 ------ #### [ YAML ] **将构件指定为操作的输入（YAML 编辑器）** 1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 1. 选择您的项目。 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择工作流的名称。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。 1. 选择**编辑**。 1. 选择 **YAML**。 1. 在要将构件指定作为输入的操作中，添加类似于以下内容的代码： ``` action-name: Inputs: Artifacts: - artifact-name ``` 有关更多示例，请参阅[构件示例](workflows-working-artifacts-ex.md)。 1. （可选）选择**验证**，在提交之前验证工作流的 YAML 代码。 1. 选择**提交**，输入提交消息，然后再次选择**提交**。 ------ # 在构件中引用文件 如果您的文件位于项目中，并且需要在某个 Amazon CodeCatalyst 工作流程操作中引用此文件，请完成以下步骤。 **注意** 另请参阅[引用源存储库文件](workflows-sources-reference-files.md)。 ------ #### [ Visual ] *不可用。选择 YAML 以查看 YAML 说明。* ------ #### [ YAML ] **引用构件中的文件（YAML 编辑器）** 1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 1. 选择您的项目。 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择工作流的名称。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。 1. 选择**编辑**。 1. 选择 **YAML**。 1. 在要引用文件的操作中，添加类似于以下内容的代码： ``` Actions: My-action: Inputs: Sources: - WorkflowSource Artifacts: - artifact-name Configuration: template: artifact-path/path/to/file.yml ``` 在前面的代码中，将： + *artifact-name*用神器的名字。 + *artifact-path*其值来自下表。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/codecatalyst/latest/userguide/workflows-working-artifacts-refer-files.html) 有关示例，请参阅 [构件示例](workflows-working-artifacts-ex.md)。 **注意** 在以下情况下，你可以省略*artifact-path*，只指定相对于工件根目录的文件路径： 包含引用的操作仅包含 `Inputs` 下的一项（例如，它包含一个输入构件而不包含任何源）。 您要引用的文件位于主输入中。*主输入*要么是 `WorkflowSource`，要么是列出的第一个输入构件（如果没有 `WorkflowSource`）。 1. （可选）选择**验证**，在提交之前验证工作流的 YAML 代码。 1. 选择**提交**，输入提交消息，然后再次选择**提交**。 ------ # 下载构件 您可以下载由您的 Amazon CodeCatalyst 工作流操作生成的构件，并进行检查以排除故障。您可以下载两种类型的构件： + **源构件** – 包含运行开始时存在的源存储库内容的快照的构件。 + **工作流构件** – 在工作流配置文件的 `Outputs` 属性中定义的构件。 **下载工作流输出的构件** 1. 通过访问 [https://codecatalyst.aws/](https://codecatalyst.aws/) 打开 CodeCatalyst 控制台。 1. 选择您的项目。 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择工作流的名称。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。 1. 在工作流的名称下，选择**运行**。 1. 在**运行历史记录**的**运行 ID** 列中，选择一个运行。例如 `Run-95a4d`。 1. 在运行的名称下，选择**构件**。 1. 在构件旁边，选择**下载**。此时会下载存档文件。其文件名由七个随机字符组成。 1. 使用您选择的档案提取实用程序来提取存档。 # 指定要使用的操作版本 默认情况下，当您向工作流程添加操作时，Amazon CodeCatalyst 会使用以下格式将完整版本添加到工作流程定义文件中： `vmajor.minor.patch` 例如： ``` My-Build-Action: Identifier: aws/build@v1.0.0 ``` 可以在 `Identifier` 属性中缩短完整版本，以便工作流始终使用操作的最新次要版本或修补版本。 例如，如果您指定： ``` My-CloudFormation-Action: Identifier: aws/cfn-deploy@v1.0 ``` ...并且最新修补版本是 `1.0.4`，那么操作将使用 `1.0.4`。如果发布了更高版本，如 `1.0.5`，那么操作将使用 `1.0.5`。如果发布了次要版本，如 `1.1.0`，那么操作将继续使用 `1.0.5`。 有关指定版本的详细说明，请参阅以下主题之一。 按照以下说明来指明您希望工作流使用哪个版本的操作。您可以指定最新的主要版本或次要版本，也可以指定特定的修补版本。 建议使用操作的最新次要版本或修补版本。 ------ #### [ Visual ] *不可用。选择 YAML 以查看 YAML 说明。* ------ #### [ YAML ] **将工作流配置为使用操作的最新版本或特定的修补版本** 1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 1. 选择您的项目。 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择工作流的名称。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。 1. 选择**编辑**。 1. 选择 **YAML**。 1. 找到要编辑其版本的操作。 1. 找到操作的 `Identifier` 属性，然后将版本设置为下列项之一： + actionidentifier @v *major* — 使用此语法让工作流程使用特定的主要版本，并允许自动选择最新的次要版本和补丁版本。 + 操作标识符 @v *major*。 *minor*— 使用此语法让工作流程使用特定的次要版本，并允许自动选择最新的补丁版本。 + 操作标识符 @v *major*。 *minor*。 *patch*— 使用此语法让工作流程使用特定的补丁版本。 **注意** 如果您不确定可用的版本，请参阅[列出可用的操作版本](workflows-action-versions-determine.md)。 **注意** 不能省略主要版本。 1. （可选）选择**验证**，在提交之前验证工作流的 YAML 代码。 1. 选择**提交**，输入提交消息，然后再次选择**提交**。 ------ # 列出可用的操作版本 按照以下说明来确定哪些版本的操作可供您在工作流中使用。 ------ #### [ Visual ] **确定哪些操作版本可用** 1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 1. 选择您的项目。 1. 找到要查看其版本的操作： 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择任意工作流的名称，或创建一个工作流。有关创建工作流的信息，请参阅[创建工作流](workflows-create-workflow.md)。 1. 选择**编辑**。 1. 在左上角，选择 **\$1 操作**打开操作目录。 1. 在下拉列表中，选择 CodeCatalyst要查看的 **Amazon** CodeCatalyst、 CodeCatalyst Labs 和第三方操作，或者选择**GitHub**查看精选 GitHub操作。 1. 搜索操作，然后选择其名称。请不要选择加号（**\$1**）。 有关该操作的详细信息将显示。 1. 在右上角附近的操作详细信息对话框中，选择**版本**下拉列表以查看该操作的可用版本列表。 ------ #### [ YAML ] *不可用。选择“可视化”以查看可视化编辑器说明。* ------ # 查看操作的源代码 您可以查看操作的源代码，以确保其中不包含危险代码、安全漏洞或其他缺陷。 按照以下说明查看[CodeCatalyst](workflows-actions.md#workflows-actions-types-cc)、[CodeCatalyst Labs](workflows-actions.md#workflows-actions-types-cc-labs) 或[第三方](workflows-actions.md#workflows-actions-types-3p)操作的源代码。 **注意** 要查看[GitHub操作](workflows-actions.md#workflows-actions-types-github)的源代码，请前往 [GitHub Marketplace](https://github.com/marketplace/actions) 中该操作的页面。该页面包含操作存储库的链接，您可以在其中找到操作的源代码。 **注意** 您无法查看以下 CodeCatalyst 操作的源代码：[构建](build-workflow-actions.md)、[测试](test-workflow-actions.md)、[GitHub 操作](integrations-github-action-add.md)。 **注意** AWS 不支持或保证操作代码或第三方操作。 GitHub **查看操作的源代码** 1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 1. 选择您的项目。 1. 找到要查看其代码的操作： 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择任意工作流的名称，或创建一个工作流。有关创建工作流的信息，请参阅[创建工作流](workflows-create-workflow.md)。 1. 选择**编辑**。 1. 在左上角，选择 **\$1 操作**打开操作目录。 1. 在下拉列表中，选择 CodeCatalyst要查看的 **Amazon** CodeCatalyst、 CodeCatalyst Labs 和第三方操作。 1. 搜索操作，然后选择其名称。请不要选择加号（**\$1**）。 有关该操作的详细信息将显示。 1. 在靠近底部的操作详细信息对话框中，选择**下载**。 出现的页面中显示操作源代码所在的 Amazon S3 存储桶。有关 Amazon S3 的信息，请参阅《Amazon Simple Storage Service 用户指南》**中的[什么是 Amazon S3？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) 1. 检查代码，确保代码符合您对质量和安全性的要求。 # 与 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**