亚马逊 CodeCatalyst 不再向新买家开放。现有客户可以继续正常使用该服务。有关更多信息，请参阅 [如何从中迁移 CodeCatalyst](migration.md)。 本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 使用工作流进行测试 在中 CodeCatalyst，您可以将测试作为不同工作流程操作（例如生成和测试）的一部分来运行。这些工作流操作都可以生成质量报告。*测试操作*是生成测试、代码覆盖率、软件组成分析和静态分析报告的工作流操作。这些报告显示在 CodeCatalyst 控制台中。 **Topics** + [质量报告类型](#test-reporting) + [添加测试操作](test-add-action.md) + [查看测试操作的结果](test-view-results.md) + [跳过操作中失败的测试](test.error-handling.md) + [与集成 universal-test-runner](test.universal-test-runner.md) + [在操作中配置质量报告](test-config-action.md) + [测试的最佳实践](test-best-practices.md) + [支持的 SARIF 属性](test.sarif.md) ## 质量报告类型 Amazon CodeCatalyst 测试操作支持以下类型的质量报告。有关如何在 YAML 中格式化这些报告的示例，请参阅[质量报告 YAML 示例](test-config-action.md#test.success-criteria-example)。 **Topics** + [测试报告](#test-reports) + [代码覆盖率报告](#test-code-coverage-reports) + [软件组成分析报告](#test-sca-reports) + [静态分析报告](#test-static-analysis-reports) ### 测试报告 在中 CodeCatalyst，您可以配置在生成期间运行的单元测试、集成测试和系统测试。然后 CodeCatalyst 可以创建包含测试结果的报告。 您可以使用测试报告来帮助解决测试问题。如果您有来自多个构建的许多测试报告，您可以使用测试报告查看失败率，以帮助您优化构建。 您可以使用以下测试报告文件格式： + Cucumber JSON (.json) + JUnit XML (.xml) + NUnit XML (.xml) + NUnit3 XML (.xml) + TestNG XML (.xml) + Visual Studio TRX（.trx、.xml） ### 代码覆盖率报告 在中 CodeCatalyst，您可以为测试生成代码覆盖率报告。 CodeCatalyst 提供了以下代码覆盖率指标： 行覆盖率 衡量测试涵盖的语句数量。语句是一条指令，不包括注释。 `line coverage = (total lines covered)/(total number of lines)` 分支覆盖率 衡量在 `if` 或 `case` 语句等控制结构的每个可能分支中，测试覆盖了多少分支。 `branch coverage = (total branches covered)/(total number of branches)` 支持以下代码覆盖率报告文件格式： + JaCoCo XML (.xml) + SimpleCov JSON（由 s [implecov 生成，而不是 simplecov](https://github.com/simplecov-ruby/simplecov)-json，[.js](https://github.com/vicentllongo/simplecov-json) on） + Clover XML（版本 3，.xml） + Cobertura XML（.xml） + LCOV（.info） ### 软件组成分析报告 在中 CodeCatalyst，您可以使用软件组成分析 (SCA) 工具来分析应用程序的组件并检查是否存在已知的安全漏洞。您可以发现并解析 SARIF 报告，其中详细列出了不同严重程度的漏洞以及修复方法。有效的严重程度值（按严重程度从高到低）为 `CRITICAL`、`HIGH`、`MEDIUM`、`LOW` 和 `INFORMATIONAL`。 支持以下 SCA 报告文件格式： + SARIF（.sarif、.json） ### 静态分析报告 您可以使用静态分析（SA）报告来识别源代码级缺陷。在中 CodeCatalyst，您可以在部署代码之前生成 SA 报告以帮助解决代码中的问题。这些问题包括错误、安全漏洞、质量问题和其它漏洞。有效的严重程度值（按严重程度从高到低）为 `CRITICAL`、`HIGH`、`MEDIUM`、`LOW` 和 `INFORMATIONAL`。 CodeCatalyst 提供了以下 SA 指标： 错误 识别源代码中可能存在的错误。这些错误可能包括有关内存安全的问题。下面是一个错误示例。 ``` // The while loop will inadvertently index into array x out-of-bounds int x[64]; while (int n = 0; n <= 64; n++) { x[n] = 0; } ``` 安全漏洞 识别源代码中可能存在的安全漏洞。这些安全漏洞可能包括以明文方式存储密钥令牌等问题。 质量问题 识别源代码中可能存在的质量问题。这些质量问题可能包括风格惯例方面的问题。下面是一个质量问题示例。 ``` // The function name doesn't adhere to the style convention of camelCase int SUBTRACT(int x, int y) { return x-y } ``` 其它漏洞 识别源代码中可能存在的其它漏洞。 CodeCatalyst 支持以下 SA 报告文件格式： + PyLint (.py) + ESLint （.js、.jsx、.ts、.tsx） + SARIF（.sarif、.json） # 添加测试操作 使用以下步骤向您的 CodeCatalyst 工作流程添加测试操作。 ------ #### [ Visual ] **使用可视化编辑器添加测试操作** 1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择工作流的名称。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。 1. 选择**编辑**。 1. 选择**可视化**。 1. 选择**操作**。 1. 在**操作**中，选择**测试**。 1. 在**输入**和**配置**选项卡中，根据需要填写字段。有关每个字段的描述，请参阅[构建和测试操作 YAML](build-action-ref.md)。本参考提供了有关在 YAML 编辑器和可视化编辑器中显示的每个字段（以及对应的 YAML 属性值）的详细信息。 1. （可选）选择**验证**，在提交之前验证工作流的 YAML 代码。 1. 选择**提交**，输入提交消息，然后再次选择**提交**。 ------ #### [ YAML ] **使用 YAML 编辑器添加构建操作** 1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择工作流的名称。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。 1. 选择**编辑**。 1. 选择 **YAML**。 1. 选择**操作**。 1. 在**操作**中，选择**测试**。 1. 根据需求修改 YAML 代码中的属性。[构建和测试操作 YAML](build-action-ref.md)中提供了每个可用属性的解释。 1. （可选）选择**验证**，在提交之前验证工作流的 YAML 代码。 1. 选择**提交**，输入提交消息，然后再次选择**提交**。 ------ ## 测试操作定义 测试操作被定义为工作流定义文件中的一组 YAML 属性。有关这些属性的信息，请参阅[工作流 YAML 定义](workflow-reference.md)中的[构建和测试操作 YAML](build-action-ref.md)。 # 查看测试操作的结果 按照以下说明查看测试操作的结果，包括生成的日志、报告和变量。 **查看测试操作的结果** 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择工作流的名称。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。 1. 在工作流程图中，选择测试操作的名称，例如**测试**。 1. 要查看操作生成的日志，请选择**日志**。将显示各个操作阶段的日志。您可以根据需要展开或折叠日志。 1. 要查看测试操作生成的测试报告，请选择**报告**，或者在导航窗格中选择**报告**。有关更多信息，请参阅 [质量报告类型](test-workflow-actions.md#test-reporting)。 1. 要查看用于测试操作的配置，请选择**配置**。有关更多信息，请参阅 [添加测试操作](test-add-action.md)。 1. 要查看测试操作使用的变量，请选择**变量**。有关更多信息，请参阅 [在工作流中使用变量](workflows-working-with-variables.md)。 # 跳过操作中失败的测试 如果您的操作有多条测试命令，您可能希望使操作中的后续测试命令能够运行，即使前一条命令失败。例如，在以下命令中，您可能希望 `test2` 始终运行，即使 `test1` 失败。 ``` Steps: - Run: npm install - Run: npm run test1 - Run: npm run test2 ``` 通常，当步骤返回错误时，Amazon CodeCatalyst 会停止该工作流程操作并将其标记为失败。通过将错误输出重定向为 `null`，可让操作步骤继续运行。您可以在命令中添加 `2>/dev/null` 来做到这一点。经过这样的修改，前面的示例就变成了下面的样子。 ``` Steps: - Run: npm install - Run: npm run test1 2>/dev/null - Run: npm run test2 ``` 在第二个代码片段中，`npm install` 命令的状态将被保留，但 `npm run test1` 命令返回的任何错误将被忽略。因此，`npm run test2` 命令就会运行。这样，无论是否发生错误，您都可以同时查看两份报告。 # 与集成 universal-test-runner 测试操作与开源命令行工具 `universal-test-runner` 集成。`universal-test-runner` 使用[测试执行协议](https://github.com/aws/universal-test-runner/blob/main/protocol/README.md)，在给定的框架内为任何语言运行测试。`universal-test-runner` 支持以下框架： + [Gradle](https://gradle.org/) + [Jest](https://jestjs.io/) + [Maven](https://maven.apache.org/) + [pytest](https://pytest.org) + [.NET](https://learn.microsoft.com/en-us/dotnet/core/tools/) `universal-test-runner` 只安装在为测试操作策管的映像上。如果将测试操作配置为使用自定义 Docker Hub 或 Amazon ECR，则必须手动安装 `universal-test-runner` 才能启用高级测试功能。为此，请在映像上安装 Node.js（14 或更高版本），然后使用 Shell 命令 `- Run: npm install -g @aws/universal-test-runner` 通过 `npm` 安装 `universal-test-runner`。有关通过 Shell 命令在容器中安装 Node.js 的更多信息，请参阅 [Installing and Updating Node Version Manager](https://github.com/nvm-sh/nvm#install--update-script)。 有关 `universal-test-runner` 的更多信息，请参阅[什么是 universal-test-runner？](https://github.com/aws/universal-test-runner#-what-is-universal-test-runner) ------ #### [ Visual ] **universal-test-runner在可视化编辑器中使用** 1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择工作流的名称。 1. 选择**编辑**。 1. 选择**可视化**。 1. 选择**操作**。 1. 在**操作**中，选择**测试**。 1. 在**配置**选项卡上，使用您选择的支持框架更新示例代码，完成 **Shell 命令**字段。例如，要使用支持的框架，可以使用类似下面的 `Run` 命令。 ``` - Run: run-tests ``` 如果您想要的框架不受支持，请考虑提供自定义适配器或运行程序。有关 **Shell 命令**字段的描述，请参阅 [Steps](build-action-ref.md#build.configuration.steps)。 1. （可选）选择**验证**，在提交之前验证工作流的 YAML 代码。 1. 选择**提交**，输入提交消息，然后再次选择**提交**。 ------ #### [ YAML ] **要 universal-test-runner在 YAML 编辑器中使用** 1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择工作流的名称。 1. 选择**编辑**。 1. 选择 **YAML**。 1. 选择**操作**。 1. 在**操作**中，选择**测试**。 1. 根据需要修改 YAML 代码。例如，要使用支持的框架，可以使用类似下面的 `Run` 命令。 ``` Configuration: Steps: - Run: run-tests ``` 如果您想要的框架不受支持，请考虑提供自定义适配器或运行程序。有关 **Steps** 属性的描述，请参阅 [Steps](build-action-ref.md#build.configuration.steps)。 1. （可选）选择**验证**，在提交之前验证工作流的 YAML 代码。 1. 选择**提交**，输入提交消息，然后再次选择**提交**。 ------ # 在操作中配置质量报告 本节介绍如何在操作中配置质量报告。 **Topics** + [自动发现和手动报告](#test.auto-discovery) + [配置报告的成功标准](#test.success-criteria) + [质量报告 YAML 示例](#test.success-criteria-example) ## 自动发现和手动报告 启用自动发现后，将 CodeCatalyst 搜索传递给操作的所有输入以及操作本身生成的所有文件，以查找测试、代码覆盖率、软件组合分析 (SCA) 和静态分析 (SA) 报告。您可以在中查看和操作每个报告 CodeCatalyst。 您还可以手动配置生成哪些报告。您可以指定要生成的报告类型和文件格式。有关更多信息，请参阅 [质量报告类型](test-workflow-actions.md#test-reporting)。 ## 配置报告的成功标准 您可以设置决定测试、代码覆盖率、软件组成分析（SCA）或静态分析（SA）报告成功标准的值。 成功标准是决定报告通过还是失败的阈值。 CodeCatalyst 首先生成您的报告，该报告可以是测试、代码覆盖率、SCA 或 SA 报告，然后将成功标准应用于生成的报告。然后说明是否达到了成功标准以及达到的程度。如果任何报告不符合指定的成功标准，则指定成功标准的 CodeCatalyst 操作将失败。 例如，当您为 SCA 报告设置成功标准时，从最严重到最不严重的有效漏洞值是：`CRITICAL`、`HIGH`、`MEDIUM`、`LOW`、`INFORMATIONAL`。如果您设置的标准是扫描一个严重程度为 `HIGH` 的漏洞，那么如果至少有一个严重程度为 `HIGH` 的漏洞，或没有严重程度为 `HIGH` 的漏洞，但至少有一个严重程度更高的漏洞，如一个严重程度为 `CRITICAL` 的漏洞，报告就会失败。 如果您不指定成功标准，那么： + 根据您的原始 CodeCatalyst 报告生成的报告不会显示成功标准。 + 成功标准不会用于确定相关工作流操作是通过还是失败。 ------ #### [ Visual ] **配置成功标准** 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择包含生成报告的操作的工作流。这是您想要为其应用成功标准的报告。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。 1. 选择**编辑**。 1. 选择**可视化**。 1. 在工作流程图中，选择已配置为生成 CodeCatalyst 报告的操作。 1. 选择**输出**选项卡。 1. 在**自动发现报告**或**手动配置报告**下，选择**成功标准**。 成功标准出现。根据您之前的选择，您可能会看到以下任一或全部选项： **通过率** 指定测试报告中必须通过测试的百分比，关联 CodeCatalyst的报告才能标记为通过。有效值包括十进制数字。例如：`50`、`60.5`。通过率标准仅适用于测试报告。有关测试报告的更多信息，请参阅[测试报告](test-workflow-actions.md#test-reports)。 **行覆盖率** 指定代码覆盖率报告中必须覆盖的行数百分比，关联 CodeCatalyst 的报告才会被标记为通过。有效值包括十进制数字。例如：`50`、`60.5`。行覆盖率标准仅适用于代码覆盖率报告。有关代码覆盖率报告的更多信息，请参阅[代码覆盖率报告](test-workflow-actions.md#test-code-coverage-reports)。 **分支覆盖率** 指定代码覆盖率报告中必须覆盖的分支百分比才能将关联 CodeCatalyst 报告标记为已通过。有效值包括十进制数字。例如：`50`、`60.5`。分支覆盖率标准仅适用于代码覆盖率报告。有关代码覆盖率报告的更多信息，请参阅[代码覆盖率报告](test-workflow-actions.md#test-code-coverage-reports)。 **漏洞（SCA）** 指定 SCA 报告中允许将关联 CodeCatalyst 报告标记为已通过的最大漏洞数量和严重性。要指定漏洞，您必须指定： + 要计入的漏洞的最低严重性。有效值（按严重程度从高到低）为 `CRITICAL`、`HIGH`、`MEDIUM`、`LOW` 和 `INFORMATIONAL`。 例如，如果您选择 `HIGH`，则将计算 `HIGH` 和 `CRITICAL` 漏洞的总数。 + 您希望允许的具有指定严重性的漏洞的最大数量。超过此数字会导致 CodeCatalyst 报告被标记为失败。有效值为整数。 漏洞标准仅适用于 SCA 报告。有关 SCA 报告的更多信息，请参阅[软件组成分析报告](test-workflow-actions.md#test-sca-reports)。 **错误** 指定 SA 报告中允许将关联 CodeCatalyst 报告标记为已通过的最大错误数量和严重性。要指定错误，您必须指定： + 要计入的错误的最低严重性。有效值（按严重程度从高到低）为 `CRITICAL`、`HIGH`、`MEDIUM`、`LOW` 和 `INFORMATIONAL`。 例如，如果您选择 `HIGH`，则将计算 `HIGH` 和 `CRITICAL` 错误的总数。 + 您希望允许的具有指定严重性的错误的最大数量。超过此数字会导致 CodeCatalyst 报告被标记为失败。有效值为整数。 错误标准仅适用于 PyLint 和 ESLint SA 报告。有关 SA 报告的更多信息，请参阅[静态分析报告](test-workflow-actions.md#test-static-analysis-reports)。 **安全漏洞** 指定 SA 报告中允许将关联 CodeCatalyst 报告标记为已通过的安全漏洞的最大数量和严重性。要指定安全漏洞，您必须指定： + 要计入的安全漏洞的最低严重性。有效值（按严重程度从高到低）为 `CRITICAL`、`HIGH`、`MEDIUM`、`LOW` 和 `INFORMATIONAL`。 例如，如果您选择 `HIGH`，则将计算 `HIGH` 和 `CRITICAL` 安全漏洞的总数。 + 您希望允许的具有指定严重性的安全漏洞的最大数量。超过此数字会导致 CodeCatalyst 报告被标记为失败。有效值为整数。 安全漏洞标准仅适用于 PyLint 和 ESLint SA 报告。有关 SA 报告的更多信息，请参阅[静态分析报告](test-workflow-actions.md#test-static-analysis-reports)。 **质量问题** 指定 SA 报告中允许将相关 CodeCatalyst 报告标记为已通过的最大质量问题数量和严重性。要指定质量问题，您必须指定： + 要计入的质量问题的最低严重性。有效值（按严重程度从高到低）为 `CRITICAL`、`HIGH`、`MEDIUM`、`LOW` 和 `INFORMATIONAL`。 例如，如果您选择 `HIGH`，则将计算 `HIGH` 和 `CRITICAL` 质量问题的总数。 + 您希望允许的具有指定严重性的质量问题的最大数量。超过此数字会导致 CodeCatalyst 报告被标记为失败。有效值为整数。 质量问题标准仅适用于 PyLint 和 ESLint SA 报告。有关 SA 报告的更多信息，请参阅[静态分析报告](test-workflow-actions.md#test-static-analysis-reports)。 1. 选择**提交**。 1. 运行您的工作流程以 CodeCatalyst 将成功标准应用于原始报告，然后重新生成包含成功标准信息的关联 CodeCatalyst 报告。有关更多信息，请参阅 [手动启动工作流运行](workflows-manually-start.md)。 ------ #### [ YAML ] **配置成功标准** 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择包含生成报告的操作的工作流。这是您想要为其应用成功标准的报告。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。 1. 选择**编辑**。 1. 选择 **YAML**。 1. 在工作流程图中，选择已配置为生成 CodeCatalyst 报告的操作。 1. 在详细信息窗格中，选择**输出**选项卡。 1. 在操作、`AutoDiscoverReports`部分或`Reports`部分中，添加一个**SuccessCriteria**属性以及、`PassRate`、`LineCoverage`、`BranchCoverage``Vulnerabilities`、`StaticAnalysisBug``StaticAnalysisSecurity`、和`StaticAnalysisQuality`属性。 有关这些属性的说明，请参阅[构建和测试操作 YAML](build-action-ref.md)。 1. 选择**提交**。 1. 运行您的工作流程以 CodeCatalyst 将成功标准应用于原始报告，然后重新生成包含成功标准信息的关联 CodeCatalyst 报告。有关启动工作流的更多信息，请参阅[手动启动工作流运行](workflows-manually-start.md)。 ------ ## 质量报告 YAML 示例 下面的示例显示了如何手动配置四份报告：测试报告、代码覆盖率报告、软件组成分析报告和静态分析报告。 ``` Reports: MyTestReport: Format: JUNITXML IncludePaths: - "*.xml" ExcludePaths: - report1.xml SuccessCriteria: PassRate: 90 MyCoverageReport: Format: CLOVERXML IncludePaths: - output/coverage/jest/clover.xml SuccessCriteria: LineCoverage: 75 BranchCoverage: 75 MySCAReport: Format: SARIFSCA IncludePaths: - output/sca/reports.xml SuccessCriteria: Vulnerabilities: Number: 5 Severity: HIGH MySAReport: Format: ESLINTJSON IncludePaths: - output/static/eslint.xml SuccessCriteria: StaticAnalysisBug: Number: 10 Severity: MEDIUM StaticAnalysisSecurity: Number: 5 Severity: CRITICAL StaticAnalysisQuality: Number: 0 Severity: INFORMATIONAL ``` # 测试的最佳实践 在使用提供的测试功能时 CodeCatalyst，我们建议您遵循以下最佳实践。 **Topics** + [自动发现](#test.best-auto-discovery) + [成功标准](#test.best-success-criteria) + [包含/排除路径](#test.best-include-exclude) ## 自动发现 在中配置操作时 CodeCatalyst，自动发现允许您自动发现各种工具（例如 JUnit 测试报告）的输出，并从中生成相关 CodeCatalyst报告。自动发现功能有助于确保，即使已发现输出的名称或路径发生变化，也能继续生成报告。添加新文件后， CodeCatalyst会自动发现它们并生成相关报告。不过，如果您使用自动发现功能，则必须考虑到该功能的以下几个方面： + 在操作中激活自动发现功能后，所有自动发现的同类型报告将共享相同的成功标准。例如，最低通过率等共享标准将适用于所有自动发现的测试报告。如果同类型的报告需要不同的标准，则必须明确配置每种报告。 + 自动发现功能还可以找到由依赖项生成的报告，如果配置了成功标准，可能会导致对这些报告的操作失败。这个问题可以通过更新排除路径配置来解决。 + 自动发现功能不能保证每次都能生成相同的报告列表，因为它会在运行时扫描操作。如果您希望始终生成特定报告，则应明确配置报告。例如，如果测试在构建过程中停止运行，测试框架就不会产生任何输出，因此也就不会生成测试报告，而且该操作可能会成功。如果您希望操作的成功与否取决于该特定测试，则必须明确配置该报告。 **提示** 开始执行新项目或现有项目时，请对整个项目目录（包括 `**/*`）使用自动发现功能。这将调用项目中的所有文件生成报告，包括子目录中的文件。 有关更多信息，请参阅 [在操作中配置质量报告](test-config-action.md)。 ## 成功标准 您可以通过配置成功标准对报告执行质量阈值。例如，如果自动发现了两份代码覆盖率报告，一份的行覆盖率为 80%，另一份的行覆盖率为 60%，则您有以下选项： + 将行覆盖率的自动发现成功标准设置为 80%。这将导致第一份报告通过，第二份报告失败，从而导致整体操作失败。要解除工作流的阻塞，请在项目中添加新测试，直到第二份报告的行覆盖率超过 80%。 + 将行覆盖率的自动发现成功标准设置为 60%。这将导致两份报告都通过，从而使操作成功。然后，您可以在第二份报告中努力提高代码覆盖率。然而，采用这种方法，您无法保证第一份报告的覆盖率不会降至 80% 以下。 + 使用可视化编辑器或为每份报告添加明确的 YAML 部分和路径，明确配置一份或两份报告。这样就可以为每份报告配置单独的成功标准和自定义名称。但是，采用这种方法时，如果报告路径发生变化，操作可能会失败。 有关更多信息，请参阅 [配置报告的成功标准](test-config-action.md#test.success-criteria)。 ## 包含/排除路径 查看操作结果时，您可以调整 CodeCatalyst 通过配置`IncludePaths`和生成的报告列表`ExcludePaths`。 + 用于`IncludePaths`指定搜索报告时 CodeCatalyst 要包含的文件和文件路径。例如，如果您指定`"/test/report/*"`，则会在操作使用的整个构建映像中 CodeCatalyst 搜索该`/test/report/`目录。当它找到该目录时， CodeCatalyst 然后在该目录中查找报告。 **注意** 对于手动配置的报告，`IncludePaths` 必须是与单个文件匹配的 glob 模式。 + 用于`ExcludePaths`指定搜索报告时 CodeCatalyst 要排除的文件和文件路径。例如，如果您指定`"/test/reports/**/*"`，则 CodeCatalyst不会在`/test/reports/`目录中搜索文件。要忽略某个目录中的所有文件，请使用 `**/*` glob 模式。 以下是可能的 glob 模式示例。 | 模式 | 说明 | | --- | --- | | `*.*` | 匹配当前目录中所有包含点的对象名称 | | `*.xml` | 匹配当前目录中所有以 `.xml` 结尾的对象名称 | | `*.{xml,txt}` | 匹配当前目录中所有以 `.xml` 或 `.txt` 结尾的对象名称 | | `**/*.xml` | 匹配所有目录中以 `.xml` 结尾的对象名称 | | `testFolder` | 匹配名为 `testFolder` 的对象，将其视为文件 | | `testFolder/*` | 匹配 `testFolder` 的子文件夹一级中的对象，如 `testFolder/file.xml` | | `testFolder/*/*` | 匹配 `testFolder` 的子文件夹两级中的对象，如 `testFolder/reportsFolder/file.xml` | | `testFolder/**` | 匹配子文件夹 `testFolder` 以及 `testFolder` 下的文件，如 `testFolder/file.xml` 和 `testFolder/otherFolder/file.xml` | CodeCatalyst 按如下方式解释全局模式： + 斜杠（`/`）字符用于分隔文件路径中的目录。 + 星号 (`*`) 字符与不跨越文件夹边界的名称组分的零个或多个字符匹配。 + 双星号 (`**`) 与所有目录中名称组分的零个或多个字符匹配。 **注意** `ExcludePaths` 优先于 `IncludePaths`。如果 `IncludePaths` 和 `ExcludePaths` 都包含同一个文件夹，则不会扫描该文件夹以获取报告。 # 支持的 SARIF 属性 静态分析结果交换格式 (SARIF) 是一种输出文件格式，可用于 Amazon 的软件组成分析 (SCA) 和静态分析报告。 CodeCatalyst下面的示例显示了如何在静态分析报告中手动配置 SARIF： ``` Reports: MySAReport: Format: SARIFSA IncludePaths: - output/sa_report.json SuccessCriteria: StaticAnalysisFinding: Number: 25 Severity: HIGH ``` CodeCatalyst 支持以下 SARIF 属性，这些属性可用于优化分析结果在报告中的显示方式。 **Topics** + [`sarifLog` 对象](#test.sarif.sarifLog) + [`run` 对象](#test.sarif.run) + [`toolComponent` 对象](#test.sarif.toolComponent) + [`reportingDescriptor` 对象](#test.sarif.reportingDescriptor) + [`result` 对象](#test.sarif.result) + [`location` 对象](#test.sarif.location) + [`physicalLocation` 对象](#test.sarif.physicalLocation) + [`logicalLocation` 对象](#test.sarif.logicalLocation) + [`fix` 对象](#test.sarif.fix) ## `sarifLog` 对象 | Name | 必需 | 描述 | | --- | --- | --- | | `$schema` | 是 | 版本 [2.1.0](https://json.schemastore.org/sarif-2.1.0.json) 的 SARIF JSON 架构的 URI。 | | `version` | 是 | CodeCatalyst 仅支持 SARIF 版本 2.1.0。 | | `runs[]` | 是 | SARIF 文件包含一个或多个运行组成的数组，每个运行代表分析工具的一次运行。 | ## `run` 对象 | Name | 必需 | 描述 | | --- | --- | --- | | `tool.driver` | 是 | 描述分析工具的 `toolComponent` 对象。 | | `tool.name` | 否 | 表示用于执行分析的工具名称的属性。 | | `results[]` | 是 | 上显示的分析工具的结果 CodeCatalyst。 | ## `toolComponent` 对象 | Name | 必需 | 描述 | | --- | --- | --- | | `name` | 是 | 分析工具的名称。 | | `properties.artifactScanned` | 否 | 工具分析的构件总数。 | | `rules[]` | 是 | 代表规则的 `reportingDescriptor` 对象数组。根据这些规则，分析工具会发现所分析代码中存在的问题。 | ## `reportingDescriptor` 对象 | Name | 必需 | 描述 | | --- | --- | --- | | `id` | 是 | 用于引用调查发现的规则的唯一标识符。 最大长度：1024 个字符 | | `name` | 否 | 规则的显示名称。 最大长度：1024 个字符 | | `shortDescription.text` | 否 | 规则的简短描述。 最大长度：3000 个字符 | | `fullDescription.text` | 否 | 规则的完整描述。 最大长度：3000 个字符 | | `helpUri` | 否 | 可以本地化的字符串，包含规则主要文档的绝对 URI。 最大长度：3000 个字符 | | `properties.unscore` | 否 | 表示扫描调查发现是否已评分的标志。 | | `properties.score.severity` | 否 | 一组固定的字符串，用于指定调查发现的严重程度。 最大长度：1024 个字符 | | `properties.cvssv3_baseSeverity` | 否 | [Common Vulnerability Scoring System v3.1](https://www.first.org/cvss/v3.1/specification-document) 的定性严重性评级。 | | `properties.cvssv3_baseScore` | 否 | CVSS v3 基本分值范围为 [0.0 - 10.0](https://nvd.nist.gov/vuln-metrics/cvss)。 | | `properties.cvssv2_severity` | 否 | 如果 CVSS v3 的值不可用，则会 CodeCatalyst 搜索 CVSS v2 值。 | | `properties.cvssv2_score` | 否 | CVSS v2 基本分值范围为 [0.0 - 10.0](https://nvd.nist.gov/vuln-metrics/cvss)。 | | `properties.severity` | 否 | 一组固定的字符串，用于指定调查发现的严重程度。 最大长度：1024 个字符 | | `defaultConfiguration.level` | 否 | 规则的默认严重性。 | ## `result` 对象 | Name | 必需 | 描述 | | --- | --- | --- | | `ruleId` | 是 | 用于引用调查发现的规则的唯一标识符。 最大长度：1024 个字符 | | `ruleIndex` | 是 | 工具组件 `rules[]` 中相关规则的索引。 | | `message.text` | 是 | 一条消息，描述结果并显示每个调查发现的消息。 最大长度：3000 个字符 | | `rank` | 否 | 一个介于 0.0 到 100.0（含）之间的值，表示结果的优先级或重要性。0.0 表示最低优先级，100.0 表示最高优先级。 | | `level` | 否 | 结果的严重性。 最大长度：1024 个字符 | | `properties.unscore` | 否 | 表示扫描调查发现是否已评分的标志。 | | `properties.score.severity` | 否 | 一组固定的字符串，用于指定调查发现的严重程度。 最大长度：1024 个字符 | | `properties.cvssv3_baseSeverity` | 否 | [Common Vulnerability Scoring System v3.1](https://www.first.org/cvss/v3.1/specification-document) 的定性严重性评级。 | | `properties.cvssv3_baseScore` | 否 | CVSS v3 基本分值范围为 [0.0 - 10.0](https://nvd.nist.gov/vuln-metrics/cvss)。 | | `properties.cvssv2_severity` | 否 | 如果 CVSS v3 的值不可用，则会 CodeCatalyst 搜索 CVSS v2 值。 | | `properties.cvssv2_score` | 否 | CVSS v2 基本分值范围为 [0.0 - 10.0](https://nvd.nist.gov/vuln-metrics/cvss)。 | | `properties.severity` | 否 | 一组固定的字符串，用于指定调查发现的严重程度。 最大长度：1024 个字符 | | `locations[]` | 是 | 检测到结果的位置集。除非只能通过在每个指定位置进行更改来纠正问题，否则只能包括一个位置。 CodeCatalyst 使用位置数组中的第一个值来注释结果。 `location` 对象的最大数量：10 | | `relatedLocations[]` | 否 | 调查发现中参考的其它位置列表。 `location` 对象的最大数量：50 | | `fixes[]` | 否 | 代表扫描工具提供的建议的`fix`对象数组。 CodeCatalyst 使用数`fixes`组中的第一个建议。 | ## `location` 对象 | Name | 必需 | 描述 | | --- | --- | --- | | `physicalLocation` | 是 | 标识构件和区域。 | | `logicalLocations[]` | 否 | 用名称描述的一组位置，不提及构件。 | ## `physicalLocation` 对象 | Name | 必需 | 描述 | | --- | --- | --- | | `artifactLocation.uri` | 是 | 表示构件位置的 URI，通常是存储库中的文件或在构建过程中生成的文件。 | | `fileLocation.uri` | 否 | 表示文件位置的回退 URI。如果 `artifactLocation.uri` 返回空，则使用此项。 | | `region.startLine` | 是 | 区域中第一个字符的行号。 | | `region.startColumn` | 是 | 区域中第一个字符的列号。 | | `region.endLine` | 是 | 区域中最后一个字符的行号。 | | `region.endColumn` | 是 | 区域中最后一个字符的列号。 | ## `logicalLocation` 对象 | Name | 必需 | 说明 | | --- | --- | --- | | `fullyQualifiedName` | 否 | 描述结果位置的其它信息。 最大长度：1024 个字符 | ## `fix` 对象 | Name | 必需 | 说明 | | --- | --- | --- | | `description.text` | 否 | 显示每个调查发现的建议的消息。 最大长度：3000 个字符 | | `artifactChanges.[0].artifactLocation.uri` | 否 | 表示需要更新的构件位置的 URI。 |