使用操作类型 - Amazon CodePipeline
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

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

使用操作类型

操作类型是您作为提供方,使用 Amazon CodePipeline中支持的集成模型之一为客户创建的预配置操作。

您可以请求、查看和更新操作类型。如果操作类型是为作为所有者的账户创建的,则可以使用 Amazon CLI 来查看或更新您的操作类型属性和结构。如果您是操作类型的提供者或所有者,则您的客户可以选择该操作,并在该操作可用后将其添加到他们的管道中 CodePipeline。

注意

您应创建 owner 字段为 custom 的作业,以便与作业辅助角色一起运行。您不能使用集成模型来创建它们。有关自定义操作的信息,请参阅在中创建和添加自定义操作 CodePipeline

操作类型组件

以下组件构成了操作类型。

  • 操作类型 IDID 由类别、所有者、提供方和版本组成。以下示例显示了一个操作类型 ID,其所有者为 ThirdParty,类别为 Test,提供方名为 TestProvider,版本为 1

    { "Category": "Test", "Owner": "ThirdParty", "Provider": "TestProvider", "Version": "1" },
  • 执行程序配置:创建操作时指定的集成模型或操作引擎。为操作类型指定执行程序时,可以选择以下两种类型之一:

    • Lambda:操作类型所有者将集成写为 Lambda 函数, CodePipeline 只要有任务可用于操作,就会调用该函数。

    • JobWorker:操作类型所有者以在客户管道上轮询可用作业的作业工作人员的身份编写集成。然后,作业工作人员运行作业,并使用 CodePipeline API 将作业结果提交回给 CodePipeline 。

      注意

      作业辅助角色集成模型不是首选的集成模型。

  • 输入和输出构件:操作类型所有者为操作客户指定的构件的限制。

  • 权限:一种权限策略,用于指定可以访问第三方操作类型的客户。可用的权限策略取决于为操作类型选择的集成模型。

  • URL:客户可以与之交互的资源的深层链接,如操作类型所有者的配置页面。

请求操作类型

当第三方提供者请求新的 CodePipeline 操作类型时,将在中为操作类型所有者创建操作类型 CodePipeline,所有者可以管理和查看该操作类型。

操作类型可以是私有操作,也可以是公有操作。创建操作类型后,操作为私有操作。要请求将操作类型更改为公共操作,请联系 CodePipeline 服务团队。

在为 CodePipeline 团队创建操作定义文件、执行者资源和操作类型请求之前,必须选择集成模型。

步骤 1:选择您的集成模型

选择您的集成模型,然后创建该模型的配置。选择集成模型后,您必须配置自己的集成资源。

  • 对于 Lambda 集成模型,您应创建 Lambda 函数并添加权限。向您的集成商 Lambda 函数添加权限,以向服务提供使用服务 CodePipeline 主体调用 CodePipeline 该函数的权限:. codepipeline.amazonaws.com 可以使用 Amazon CloudFormation 或命令行添加权限。

    • 使用 Amazon CloudFormation添加权限的示例:

      CodePipelineLambdaBasedActionPermission: Type: 'AWS::Lambda::Permission' Properties: Action: 'lambda:invokeFunction' FunctionName: {"Fn::Sub": "arn:${AWS::Partition}:lambda:${AWS::Region}:${AWS::AccountId}:function:function-name"} Principal: codepipeline.amazonaws.com
    • 命令行文档

  • 对于求职者集成模型,您可以使用允许的账户列表创建集成,在这些账户中,作业工作人员使用 CodePipeline API 轮询职位。

步骤 2:创建操作类型定义文件

您应使用 JSON 格式,在操作类型定义文件中定义一种操作类型。在该文件中,您可以包括操作类别、用于管理操作类型的集成模型,以及配置属性。

注意

在创建公有操作后,您无法将 properties 下的操作类型属性从 optional 更改为 required。您也不能更改 owner

有关操作类型定义文件参数的更多信息,请参阅 CodePipeline API 参考UpdateActionType中的ActionTypeDeclaration和。

操作类型定义文件中有八个部分:

  • description:要更新的操作类型的描述。

  • executor:与使用支持的集成模型(Lambdajob worker)创建的操作类型的执行程序相关的信息。根据您的执行程序类型,您只能提供 jobWorkerExecutorConfigurationlambdaExecutorConfiguration

    • configuration:基于所选择的集成模型,用于操作类型配置的资源。对于 Lambda 集成模型,请使用 Lambda 函数 ARN。对于作业辅助角色集成模型,请使用作业辅助角色从中运行的账户或账户列表。

    • jobTimeout:作业的超时(以秒为单位)。一个操作执行可以包含多个作业。这是单个作业的超时,而不是整个操作执行的超时。

      注意

      对于 Lambda 集成模型,最大超时为 15 分钟。

    • policyStatementsTemplate:政策声明,它指定了 CodePipeline 客户账户中成功运行操作执行所需的权限。

    • type:用于创建和更新操作类型的集成模型,可以是 LambdaJobWorker

  • id:操作类型的类别、所有者、提供方和版本 ID:

    • category:可在阶段中执行的操作类型:源、构建、部署、测试、调用或批准。

    • provider:被调用的操作类型的提供方,如提供方公司或产品名称。提供方名称应在创建操作类型时提供。

    • owner:被调用的操作类型的创建者:AWSThirdParty

    • version:用于对操作类型进行版本控制的字符串。对于第一个版本,应将版本号设置为 1。

  • inputArtifactDetails:预计来自管道上一阶段的构件数量。

  • outputArtifactDetails:预计操作类型阶段的结果所产生的构件数量。

  • permissions:用于识别有权使用操作类型的账户的详细信息。

  • properties:完成项目任务所需的参数。

    • description:显示给用户的属性的说明。

    • optional:配置属性是否为可选。

    • noEcho:日志中是否省略由客户输入的字段值。如果true,则在与 GetPipeline API 请求一起返回时,该值将被删除。

    • key:配置属性是否为一个键。

    • queryable:属性是否与轮询一起使用。一个操作类型最多可以有一个可查询属性。如果它有一个可查询属性,该属性必须是必需的且不是私有的。

    • name:向用户显示的属性名称。

  • urls:向您的用户 CodePipeline 显示网址列表。

    • entityUrlTemplate:操作类型的外部资源(如配置页面)的 URL。

    • executionUrlTemplate:最新操作执行的详细信息的 URL。

    • revisionUrlTemplate: CodePipeline控制台中显示的指向客户可以更新或更改外部操作配置的页面的 URL。

    • thirdPartyConfigurationUrl:页面的 URL,用户可在该页面中注册外部服务,并对该服务提供的操作执行初始配置。

以下代码展示了一个操作类型定义文件示例。

{ "actionType": { "description": "string", "executor": { "configuration": { "jobWorkerExecutorConfiguration": { "pollingAccounts": [ "string" ], "pollingServicePrincipals": [ "string" ] }, "lambdaExecutorConfiguration": { "lambdaFunctionArn": "string" } }, "jobTimeout": number, "policyStatementsTemplate": "string", "type": "string" }, "id": { "category": "string", "owner": "string", "provider": "string", "version": "string" }, "inputArtifactDetails": { "maximumCount": number, "minimumCount": number }, "outputArtifactDetails": { "maximumCount": number, "minimumCount": number }, "permissions": { "allowedAccounts": [ "string" ] }, "properties": [ { "description": "string", "key": boolean, "name": "string", "noEcho": boolean, "optional": boolean, "queryable": boolean } ], "urls": { "configurationUrl": "string", "entityUrlTemplate": "string", "executionUrlTemplate": "string", "revisionUrlTemplate": "string" } } }

第 3 步:注册您的集成 CodePipeline

要向注册您的操作类型 CodePipeline,请联系 CodePipeline 服务团队并提出您的请求。

CodePipeline 服务团队通过更改服务代码库来注册新的操作类型集成。 CodePipeline 登记了两项新诉讼:一项公共诉讼和一项私人诉讼。您应使用私有操作进行测试,然后在准备就绪后,激活公有操作来为客户流量提供服务。

注册 Lambda 集成请求
  • 使用以下表格向 CodePipeline 服务团队发送请求。

    This issue will track the onboarding of [Name] in CodePipeline. [Contact engineer] will be the primary point of contact for this integration. Name of the action type as you want it to appear to customers: Example.com Testing Initial onboard checklist: 1. Attach an action type definition file in JSON format. This includes the schema for the action type 2. A list of test accounts for the allowlist which can access the new action type [{account, account_name}] 3. The Lambda function ARN 4. List of Amazon Web Services 区域 where your action will be available 5. Will this be available as a public action?
注册作业辅助角色集成请求
  • 使用以下表格向 CodePipeline 服务团队发送请求。

    This issue will track the onboarding of [Name] in CodePipeline. [Contact engineer] will be the primary point of contact for this integration. Name of the action type as you want it to appear to customers: Example.com Testing Initial onboard checklist: 1. Attach an action type definition file in JSON format. This includes the schema for the action type. 2. A list of test accounts for the allowlist which can access the new action type [{account, account_name}] 3. URL information: Website URL: https://www.example.com/%TestThirdPartyName%/%TestVersionNumber% Example URL pattern where customers will be able to review their configuration information for the action: https://www.example.com/%TestThirdPartyName%/%customer-ID%/%CustomerActionConfiguration% Example runtime URL pattern: https://www.example.com/%TestThirdPartyName%/%customer-ID%/%TestRunId% 4. List of Amazon Web Services 区域 where your action will be available 5. Will this be available as a public action?

步骤 4:激活您的新集成

当您准备好公开使用新的集成时,请联系 CodePipeline 服务团队。

向管道添加可用的操作类型(控制台)

您可以将自己的操作类型添加到管道中,以便对其进行测试。为此,您可以创建新管道或编辑现有管道。

注意

如果您的操作类型是源、构件或部署类操作,则可以通过创建管道来添加该操作。如果您的操作类型属于测试类别,则您必须通过编辑现有管道来添加。

从 CodePipeline 控制台向现有管道添加操作类型
  1. 登录 Amazon Web Services Management Console 并打开 CodePipeline 控制台,网址为 http://console.aws.amazon.com/codesuite/codepipeline/home

  2. 在管道列表中,选择要在其中添加操作类型的管道。

  3. 在管道的摘要视图页面中,选择编辑

  4. 选择编辑阶段。在要向其添加操作类型的阶段中,选择添加操作组。此时将显示编辑操作页面。

  5. 编辑操作页面的操作名称下,输入操作的名称。这是为管道中的阶段显示的名称。

  6. 操作提供程序中,从列表中选择您的操作类型。

    请注意,列表中的值基于操作类型定义文件中指定的 provider

  7. 输入构件中,按照以下格式输入构件名称:

    Artifactname::FileName

    请注意,所允许的最小和最大数量基于操作类型定义文件中指定的 inputArtifactDetails

  8. 选择连接到 <Action_Name>

    此时将打开一个浏览器窗口,并连接到您为操作类型创建的网站。

  9. 以客户身份登录您的网站,完成客户为使用您的操作类型而应采取的步骤。您的步骤将会根据操作类别、网站和配置而有所不同,但通常会包含一个完成操作,使客户返回编辑操作页面。

  10. 在 CodePipeline “编辑” 操作页面中,将显示该操作的其他配置字段。所显示的字段是您在操作定义文件中指定的配置属性。在为您的操作类型自定义的字段中输入信息。

    例如,如果操作定义文件指定了一个名为 Host 的属性,则操作的编辑操作页面上会显示一个带有主机标签的字段。

  11. 输出构件中,按照以下格式输入构件名称:

    Artifactname::FileName

    请注意,所允许的最小和最大数量基于操作类型定义文件中指定的 outputArtifactDetails

  12. 选择完成以返回管道详细信息页面。

    注意

    您的客户可以选择使用 CLI 将操作类型添加到他们的管道中。

  13. 要测试您的操作,请向管道源阶段中指定的源提交更改,或者按照手动启动管道中的步骤进行操作。

要创建包含您的操作类型的管道,请按照在中创建管道 CodePipeline中的步骤操作,并从您将测试的众多阶段中选择自己的操作类型。

查看操作类型

您可以使用 CLI 查看操作类型。使用 get-action-type 命令可以查看使用集成模型创建的操作类型。

查看操作类型
  1. 创建一个输入 JSON 文件并将该文件命名为 file.json。以 JSON 格式添加您的操作类型 ID,如以下示例所示。

    { "category": "Test", "owner": "ThirdParty", "provider": "TestProvider", "version": "1" }
  2. 在终端窗口或命令行中,运行 get-action-type 命令。

    aws codepipeline get-action-type --cli-input-json file://file.json

    此命令会返回操作类型的操作定义输出。此示例显示了一个使用 Lambda 集成模型创建的操作类型。

    { "actionType": { "executor": { "configuration": { "lambdaExecutorConfiguration": { "lambdaFunctionArn": "arn:aws:lambda:us-west-2:<account-id>:function:my-function" } }, "type": "Lambda" }, "id": { "category": "Test", "owner": "ThirdParty", "provider": "TestProvider", "version": "1" }, "inputArtifactDetails": { "minimumCount": 0, "maximumCount": 1 }, "outputArtifactDetails": { "minimumCount": 0, "maximumCount": 1 }, "permissions": { "allowedAccounts": [ "<account-id>" ] }, "properties": [] } }

更新操作类型

您可以使用 CLI 来编辑使用集成模型创建的操作类型。

对于公有操作类型,您无法更新所有者,也无法将可选属性更改为必需属性,并且只能添加新的可选属性。

  1. 使用 get-action-type 命令获取您的操作类型的结构。复制该结构。

  2. 创建一个输入 JSON 文件并将其命名为 action.json。将您在上一步中复制的操作类型结构粘贴到其中。更改您要更新的任何参数。您也可以添加可选的参数。

    有关输入文件参数的更多信息,请参阅步骤 2:创建操作类型定义文件中的操作定义文件。

    下面的示例展示了如何更新使用 Lambda 集成模型创建的操作类型。此示例中将做出以下更改:

    • provider 名称更改为 TestProvider1

    • 添加 900 秒的作业超时限制。

    • 添加名为 Host 的操作配置属性,该属性将向使用该操作客户显示。

      { "actionType": { "executor": { "configuration": { "lambdaExecutorConfiguration": { "lambdaFunctionArn": "arn:aws:lambda:us-west-2:<account-id>:function:my-function" } }, "type": "Lambda", "jobTimeout": 900 }, "id": { "category": "Test", "owner": "ThirdParty", "provider": "TestProvider1", "version": "1" }, "inputArtifactDetails": { "minimumCount": 0, "maximumCount": 1 }, "outputArtifactDetails": { "minimumCount": 0, "maximumCount": 1 }, "permissions": { "allowedAccounts": [ "account-id" ] }, "properties": { "description": "Owned build action parameter description", "optional": true, "noEcho": false, "key": true, "queryable": false, "name": "Host" } } }
  3. 在终端或命令行中,运行 update-action-type 命令。

    aws codepipeline update-action-type --cli-input-json file://action.json

    此命令会返回与更新后的参数相匹配的操作类型输出。