本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
使用動作類型
動作類型是您身為提供者的預先設定動作,可在 AWS CodePipeline中使用其中一個支援的整合模型,為客戶建立這些動作。
您可以要求、檢視和更新動作類型。如果動作類型是以擁有者身分為您的帳戶建立的,您可以使用 AWS CLI 來檢視或更新動作類型內容和結構。如果您是動作類型的提供者或擁有者,您的客戶可以選擇該動作,並在中提供動作後將其新增至其管道 CodePipeline。
注意
您可以在owner
欄位custom
中建立要與工作 Worker 一起執行的動作。您不使用整合模型建立它們。如需有關自訂動作的資訊,請參閱在 CodePipeline 中建立和新增自訂動作。
動作類型元件
下列元件構成動作類型。
-
動作類型 ID — ID 由類別、擁有者、提供者和版本組成。下列範例顯示具有擁有者、類別
ThirdParty
、名為TestProvider
的Test
提供者以及版本的動作類型 ID1
。{ "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
。可以使用 AWS CloudFormation 或命令行添加權限。-
使用以 AWS 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
-
-
對於工作 Worker 整合模型,您可以使用允許的帳戶清單建立整合,其中工作者會輪詢使用 CodePipeline API 的工作。
步驟 2:建立動作類型定義檔
您可以使用 JSON 在動作類型定義檔案中定義動作類型。在檔案中,您可以包括動作類別、用於管理動作類型的整合模型,以及組態屬性。
注意
建立公用動作之後,您無法將下方的動作類型屬性properties
從變更optional
為required
。您也無法變更owner
.
如需有關動作類型定義檔案參數的詳細資訊,請參閱 CodePipeline API 參考UpdateActionType中的ActionTypeDeclaration和。
動作類型定義檔案中有八個區段:
-
description
:要更新之動作類型的說明。 -
executor
:使用支援整合模型 (Lambda
或job worker
) 建立之動作類型之執行程式的相關資訊。您只能根據您的執行人類型提供jobWorkerExecutorConfiguration
或lambdaExecutorConfiguration
。-
configuration
:動作類型組態的資源,以選擇的整合模型為基礎。對於 Lambda 整合模型,請使用 Lambda 函數 ARN。對於工作 Worker 整合模型,請使用工作 Worker 執行來源的帳戶或帳戶清單。 -
jobTimeout
:工作的逾時時間 (秒)。一個動作執行可以包含多個工作。這是單一工作的逾時,而不是整個動作執行。注意
對於 Lambda 整合模型,逾時時間上限為 15 分鐘。
-
policyStatementsTemplate
:指定客戶帳 CodePipeline 戶中成功執行動作所需權限的政策陳述式。 -
type
:用來建立和更新動作類型 (Lambda
或) 的整合模型JobWorker
。
-
-
id
:動作類型的類別、擁有者、提供者和版本 ID:-
category
:可以在階段中採取的動作類型:來源、建置、部署、測試、叫用或核准。 -
provider
:所呼叫動作類型的提供者,例如提供者公司或產品名稱。建立動作類型時會提供提供者名稱。 -
owner
:所呼叫之動作類型的建立者:AWS
或ThirdParty
。 -
version
:用來版本化動作類型的字串。對於第一個版本,將版本號碼設定為 1。
-
-
inputArtifactDetails
:管道中上一個階段的預期成品數量。 -
outputArtifactDetails
:動作類型階段的結果所預期的成品數目。 -
permissions
:識別具有使用動作類型之權限之帳戶的詳細資訊。 -
properties
:完成專案作業所需的參數。-
description
:顯示給使用者的屬性說明。 -
optional
:是否配置屬性是可選的。 -
noEcho
:是否從日誌中省略客戶輸入的字段值。如果true
,則當使用 GetPipeline API 請求傳回時,會編輯該值。 -
key
:組態屬性是否為索引鍵。 -
queryable
:該屬性是否與輪詢一起使用。一個動作類型最多可以有一個可查詢的屬性。如果有,則該屬性必須是必要的,而且不是私密。 -
name
:顯示給使用者的屬性名稱。
-
-
urls
:URL 清單會 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 AWS 區域 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 AWS 區域 where your action will be available 5. Will this be available as a public action?
步驟 4:啟用您的新整合
當您準備好公開使用新的整合時,請與 CodePipeline 服務團隊聯絡。
將可用的動作類型新增至管線 (主控台)
您可以將動作類型新增至管線,以便對其進行測試。您可以透過建立新配管或編輯現有配管來執行此操作。
注意
如果您的動作類型是來源、組建或部署類別動作,您可以透過建立管線來新增它。如果您的動作類型位於測試類別中,則必須透過編輯現有管線來新增動作類型。
若要從 CodePipeline 主控台將動作類型新增至現有管線
請登入 AWS Management Console 並開啟 CodePipeline 主控台,網址為 http://console.aws.amazon.com/codesuite/codepipeline/home
。 -
在配管清單中,選擇要新增動作類型的配管。
-
在配管的摘要檢視頁面上,選擇 「編輯」(Edit)。
-
選擇編輯階段。在您要新增動作類型的階段中,選擇 [新增動作群組]。「編輯」動作頁面隨即顯示。
-
在 [編輯動作] 頁面上的 [動作名稱] 中,輸入動作的名稱。這是管線中階段所顯示的名稱。
-
在 [動作提供者] 中,從清單中選擇您的動作類型。
請注意,清單中的值是以動作類型定義檔案中
provider
指定的值為基礎。 -
在輸入人工因素中,以下列格式輸入人工因素名稱:
Artifactname
::FileName
請注意,允許的最小和最大數量是根據動作類型定義檔案中
inputArtifactDetails
指定的數量來定義的。 -
選擇「Connect 至」<Action_Name>。
瀏覽器視窗隨即開啟,並連線至您針對動作類型建立的網站。
-
以客戶身份登錄到您的網站,並完成客戶使用您的操作類型所採取的步驟。您的步驟會根據您的動作類別、網站和設定而有所不同,但通常會包含將客戶返回 「編輯動作」頁面的完成動作。
-
在 CodePipeline 「編輯」動作頁面中,會顯示動作的其他組態欄位。顯示的欄位是您在動作定義檔案中指定的組態特性。在針對您的動作類型自訂的欄位中輸入資訊。
例如,如果動作定義檔案指定了名為的屬性
Host
,則標籤為「主機」(Host) 的欄位會顯示在您動作的「編輯」動作頁面上。 -
在輸出人工因素中,以下列格式輸入人工因素名稱:
Artifactname
::FileName
請注意,允許的最小和最大數量是根據動作類型定義檔案中
outputArtifactDetails
指定的數量來定義的。 -
選擇「完成」以返回管線詳細資訊頁面。
注意
您的客戶可以選擇性地使用 CLI 將動作類型新增至其管道。
-
若要測試您的動作,請將變更送至管線的來源階段中指定的來源,或遵循手動啟動管線中的步驟執行。
若要使用您的動作類型建立管道,請遵循中的步驟,建立管道、階段和動作並從您要測試的階段中選擇動作類型。
檢視動作類型
您可以使用 CLI 檢視動作類型。使用指get-action-type令可檢視已使用整合模型建立的動作類型。
若要檢視動作類型
-
創建一個輸入 JSON 文件並命名該文件
file.json
。以 JSON 格式新增動作類型 ID,如下列範例所示。{ "category": "Test", "owner": "ThirdParty", "provider": "TestProvider", "version": "1" }
-
在終端機視窗或命令列中,執行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 編輯使用整合模型建立的動作類型。
對於公用動作類型,您無法更新擁有者、無法將選用屬性變更為必要屬性,而且只能新增新的選用屬性。
-
使用
get-action-type
指令取得動作類型的結構。複製結構。 -
創建一個輸入 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
" }
-
-
在終端機或命令列中,執行update-action-type命令
aws codepipeline update-action-type --cli-input-json file://action.json
此指令會傳回動作類型輸出,以符合您更新的參數。