本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # CodePipeline 故障診斷 以下資訊可能有助於診斷 AWS CodePipeline內的常見問題。 **Topics** + [管道錯誤：使用 設定的管道會 AWS Elastic Beanstalk 傳回錯誤訊息：「部署失敗。提供的角色未擁有足夠許可：Service:AmazonElasticLoadBalancing」](#troubleshooting-aeb1) + [部署錯誤：如果缺少「DescribeEvents」許可，使用 AWS Elastic Beanstalk 部署動作設定的管道會停止回應，而不是失敗](#troubleshooting-aeb2) + [管道錯誤：來源動作會傳回許可不足訊息：「無法存取 CodeCommit 儲存庫 `repository-name`。請確認管道 IAM 角色擁有存取該程式庫所需的足夠許可。」](#troubleshooting-service-role-permissions) + [管道錯誤：Jenkins 建置或測試動作在一段長時間的執行後，因為缺乏登入資料或許可而失敗。](#troubleshooting-jen1) + [管道錯誤：使用在另一個 AWS 區域中建立的儲存貯體在某個 AWS 區域中建立的管道會傳回代碼為 "JobFailed" 的 "InternalError"](#troubleshooting-reg-1) + [部署錯誤：包含 WAR 檔案的 ZIP 檔案已成功部署至 AWS Elastic Beanstalk，但應用程式 URL 回報找不到 404 錯誤](#troubleshooting-aeb2) + [管道成品資料夾名稱似乎被截斷了](#troubleshooting-truncated-artifacts) + [新增連線至 Bitbucket、GitHub、GitHub Enterprise Server 或 GitLab.com 的 CodeBuild GitClone 許可 GitLab.com](#codebuild-role-connections) + [為 CodeCommit 來源動作新增 CodeBuild GitClone 許可](#codebuild-role-codecommitclone) + [管道錯誤：採用 CodeployToECS 動作的部署會傳回錯誤訊息：「嘗試從 <來源成品名稱> 讀取工作定義成品檔案時發生例外狀況」](#troubleshooting-ecstocodedeploy-size) + [GitHub （透過 OAuth 應用程式） 來源動作：儲存庫清單會顯示不同的儲存庫](#troubleshooting-connections-GitHub-org) + [GitHub （透過 GitHub 應用程式） 來源動作：無法完成儲存庫的連線](#troubleshooting-connections-GitHub-admin) + [Amazon S3 錯誤：CodePipeline 服務角色 取得 S3 儲存貯體 的 S3 存取遭拒](#troubleshooting-S3-access-denied-list) + [具有 Amazon S3、Amazon ECR 或 CodeCommit 來源的管道不會再自動啟動](#troubleshooting-events-identifiers) + [連線至 GitHub 時發生連線錯誤：「發生問題，請確定您的瀏覽器已啟用 Cookie」或「組織擁有者必須安裝 GitHub 應用程式」](#troubleshooting-connections-GitHub-organization-owner) + [達到執行限制時，執行模式變更為 QUEUED 或 PARALLEL 模式的管道會失敗](#troubleshooting-queued-mode) + [如果變更為 QUEUED 或 SUPERSEDED 模式時編輯過了 PARALLEL 模式的管道定義](#troubleshooting-execution-mode-editing) + [從 PARALLEL 模式變更的管道會顯示先前的執行模式](#troubleshooting-execution-mode-displayedstate) + [具有使用檔案路徑觸發篩選之連線的管道可能不會在分支建立時開始](#troubleshooting-file-paths-filtering) + [當達到檔案限制時，具有使用檔案路徑觸發篩選之連線的管道可能無法啟動](#troubleshooting-file-paths-files) + [PARALLEL 模式中的 CodeCommit 或 S3 來源修訂可能與 EventBridge 事件不相符](#troubleshooting-revisions-parallel) + [EC2 部署動作失敗並顯示錯誤訊息 `No such file`](#troubleshooting-ec2-deploy) + [EKS 部署動作失敗並顯示`cluster unreachable`錯誤訊息](#troubleshooting-eks-deploy) + [需要不同問題的協助嗎？](#troubleshooting-other) ## 管道錯誤：使用 設定的管道會 AWS Elastic Beanstalk 傳回錯誤訊息：「部署失敗。提供的角色未擁有足夠許可：Service:AmazonElasticLoadBalancing」 **問題：**CodePipeline 的服務角色沒有足夠的許可 AWS Elastic Beanstalk，包括但不限於 Elastic Load Balancing 中的某些操作。CodePipeline 的服務角色已於 2015 年 8 月 6 日更新，以解決此問題。在此日期前建立其服務角色的客戶，必須修改服務角色的政策陳述式以新增必要許可。 **可能的修正：**最簡單的解決方案是編輯服務角色的政策陳述式，詳述於[將許可新增至 CodePipeline 服務角色](how-to-custom-role.md#how-to-update-role-new-services)中。 套用編輯的政策後，請依照中的步驟[手動啟動管道](pipelines-rerun-manually.md)手動重新執行任何使用 Elastic Beanstalk 的管道。 根據您的安全性需求，也可以使用其他方式修改許可。 ## 部署錯誤：如果缺少「DescribeEvents」許可，使用 AWS Elastic Beanstalk 部署動作設定的管道會停止回應，而不是失敗 **問題：**CodePipeline 的服務角色必須包含任何使用 管道`"elasticbeanstalk:DescribeEvents"`的動作 AWS Elastic Beanstalk。如果沒有此許可， AWS Elastic Beanstalk 部署動作會停止，而不會失敗或指出錯誤。如果您的服務角色缺少此動作，則 CodePipeline 沒有 AWS Elastic Beanstalk 代表您在 中執行管道部署階段的許可。 **可能的修正：**檢閱 CodePipeline 服務角色。如果 `"elasticbeanstalk:DescribeEvents"` 動作遺失，請使用[將許可新增至 CodePipeline 服務角色](how-to-custom-role.md#how-to-update-role-new-services) 中的步驟並使用 **Edit Policy (編輯政策)** 功能將它加入 IAM 主控台。 套用編輯的政策後，請依照中的步驟[手動啟動管道](pipelines-rerun-manually.md)手動重新執行任何使用 Elastic Beanstalk 的管道。 ## 管道錯誤：來源動作會傳回許可不足訊息：「無法存取 CodeCommit 儲存庫 `repository-name`。請確認管道 IAM 角色擁有存取該程式庫所需的足夠許可。」 **問題：**CodePipeline 的服務角色沒有足夠的 CodeCommit 許可，並且可能在 2016 年 4 月 18 日新增對 CodeCommit 儲存庫的支援之前建立。在此日期前建立其服務角色的客戶，必須修改服務角色的政策陳述式以新增必要許可。 **可能的修正：**將 CodeCommit 所需的許可新增至 CodePipeline 服務角色的政策。如需詳細資訊，請參閱[將許可新增至 CodePipeline 服務角色](how-to-custom-role.md#how-to-update-role-new-services)。 ## 管道錯誤：Jenkins 建置或測試動作在一段長時間的執行後，因為缺乏登入資料或許可而失敗。 **問題：**如果 Jenkins 伺服器安裝在 Amazon EC2 執行個體上，執行個體可能尚未使用具有 CodePipeline 所需許可的執行個體角色建立。如果您在 Jenkins 伺服器、現場部署執行個體或在沒有必要 IAM 角色的情況下建立的 Amazon EC2 執行個體上使用 IAM 使用者，IAM 使用者可能沒有所需的許可，或 Jenkins 伺服器無法透過伺服器上設定的設定檔存取這些登入資料。 **可能的修正：**確定 Amazon EC2 執行個體角色或 IAM 使用者已使用 `AWSCodePipelineCustomActionAccess`受管政策或同等許可進行設定。如需詳細資訊，請參閱[AWS 的 受管政策 AWS CodePipeline](managed-policies.md)。 如果您使用的是 IAM 使用者，請確定執行個體上設定的 AWS 設定檔使用已設定正確許可的 IAM 使用者。您可能需要提供為 Jenkins 和 CodePipeline 之間整合而設定的 IAM 使用者登入資料，直接與 Jenkins 使用者介面整合。這不是建議的最佳實務。若您必須執行此作業，請確認 Jenkins 伺服器為安全並使用 HTTPS 而非 HTTP。 ## 管道錯誤：使用在另一個 AWS 區域中建立的儲存貯體在某個 AWS 區域中建立的管道會傳回代碼為 "JobFailed" 的 "InternalError" **問題：**如果在不同 AWS 區域中建立管道和儲存貯體，則下載存放在 Amazon S3 儲存貯體中的成品將會失敗。 **可能的修正：**確定存放成品的 Amazon S3 儲存貯體與您建立的管道位於相同的 AWS 區域。 ## 部署錯誤：包含 WAR 檔案的 ZIP 檔案已成功部署至 AWS Elastic Beanstalk，但應用程式 URL 回報找不到 404 錯誤 **問題：**WAR 檔案已成功部署到 AWS Elastic Beanstalk 環境，但應用程式 URL 卻傳回「404 找不到」錯誤。 **可能的修正：** AWS Elastic Beanstalk 可以解壓縮 ZIP 檔案，但不能解壓縮 ZIP 檔案中包含的 WAR 檔案。請改為指定包含要部署內容的資料夾，而非您 `buildspec.yml` 檔案中的 WAR 檔案。例如： ``` version: 0.2 phases: post_build: commands: - mvn package - mv target/my-web-app ./ artifacts: files: - my-web-app/**/* discard-paths: yes ``` 如需範例，請參閱 [AWS Elastic Beanstalk CodeBuild 的範例](https://docs.aws.amazon.com/codebuild/latest/userguide/sample-elastic-beanstalk.html)。 ## 管道成品資料夾名稱似乎被截斷了 **問題：**當您在 CodePipeline 中檢視管道成品名稱時，名稱似乎被截斷。這可能使名稱看起來都很相似或似乎不再包含整個管道名稱。 **說明：**CodePipeline 會截斷成品名稱，以確保當 CodePipeline 為任務工作者產生臨時登入資料時，完整的 Amazon S3 路徑不會超過政策大小限制。 即使成品名稱似乎被截斷，CodePipeline 會以不受截斷名稱成品影響的方式映射到成品儲存貯體。該管道可以正常運作。這不是資料夾或成品的問題。管道名稱有 100 個字元的限制。雖然成品資料夾名稱看起來可能變短了，對管道來說仍然是唯一的。 ## 新增連線至 Bitbucket、GitHub、GitHub Enterprise Server 或 GitLab.com 的 CodeBuild GitClone 許可 GitLab.com 當您在來源動作和 CodeBuild 動作 AWS CodeConnections 中使用 時，有兩種方式可以將輸入成品傳遞至組建： + 預設：來源動作會產生 zip 檔案，其中包含 CodeBuild 下載的程式碼。 + 完全複製：原始程式碼可以直接下載到建置環境。 完整複製模式可讓您以工作 Git 儲存庫的形式與原始碼互動。若要使用此模式，您必須准許 CodeBuild 環境使用連線。 若要將許可新增至 CodeBuild 服務角色政策，您可以建立連接至 CodeBuild 服務角色的客戶受管政策。下列步驟會建立政策，其中在 `action` 欄位中指定`UseConnection`許可、`Resource`在 欄位中指定連線 ARN，以及透過 限制來源儲存庫 ID`Condition`。 **使用主控台新增 UseConnection 許可** 1. 若要尋找管道的連線 ARN 和來源儲存庫 ID，請開啟您的管道，按一下來源動作上的 (i) 圖示，然後切換到**輸入**索引標籤。 連線 ARN 的範例如下： ``` arn:aws:codeconnections:eu-central-1:123456789123:connection/sample-1908-4932-9ecc-2ddacee15095 ``` 來源儲存庫 ID 的範例： ``` owner/test-app ``` 您可以將連線 ARN 和儲存庫 ID 新增至 CodeBuild 服務角色政策。 1. 若要尋找 CodeBuild 服務角色，請選擇管道中使用的建置專案，然後導覽至**建置詳細資訊**索引標籤。 1. 選擇 **Service role (服務角色)** 連結。這會開啟 IAM 主控台，讓您新增政策以授予存取您的連線。 1. 在 IAM 主控台中，選擇**新增許可**，然後選擇**建立內嵌政策**。 使用下列政策範本範例。在 `Resource` 欄位中新增您的連線 ARN，並在 `codeconnections:FullRepositoryId` `Condition` 欄位中新增您的儲存庫 ID，如本範例所示： ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "codeconnections:UseConnection", "Resource": "arn:aws:codeconnections:eu-central-1:123456789123:connection/my-connection-id", "Condition": { "StringEquals": { "codeconnections:FullRepositoryId": "my-repository-id" } } } ] } ``` ------ 使用 `Condition` 欄位，根據您的建置規格需求進一步縮小政策許可的範圍 （請參閱`CodeConnection`條件[文件](https://docs.aws.amazon.com/dtconsole/latest/userguide/security-iam.html#permissions-reference-connections-use))。 在 **JSON** 索引標籤上，貼上您的政策。 1. 選擇**下一步**。輸入政策的名稱 (例如 **connection-permissions**)，然後選擇 **Create policy (建立政策)**。 您將看到**connection-permissions**連接到角色**許可政策的政策**。 ## 為 CodeCommit 來源動作新增 CodeBuild GitClone 許可 當您的管道具有 CodeCommit 來源動作時，有兩種方式可以將輸入成品傳遞至組建： + **預設** – 來源動作會產生包含 CodeBuild 下載程式碼的 zip 檔案。 + **完全複製** – 原始程式碼可以直接下載到建置環境。 **完整複製**選項可讓您以工作 Git 儲存庫的形式與原始程式碼互動。若要使用此模式，您必須新增 CodeBuild 環境的許可，才能從儲存庫中提取。 若要將許可新增至 CodeBuild 服務角色政策，您可以建立連接至 CodeBuild 服務角色的客戶受管政策。下列步驟會建立政策，在 `action` 欄位中指定 `codecommit:GitPull`許可。 **使用主控台新增 GitPull 許可** 1. 若要尋找 CodeBuild 服務角色，請開啟管道中使用的建置專案，然後瀏覽至 **Build details (建置詳細資訊)** 索引標籤。 1. 選擇 **Service role (服務角色)** 連結。這會開啟 IAM 主控台，您可以在其中新增授予儲存庫存取權的新政策。 1. 在 IAM 主控台，選擇 **Attach policies (連接政策)**，然後選擇 **Create policy (建立政策)**。 1. 在 **JSON** 索引標籤上，貼上下列範例政策。 ``` { "Action": [ "codecommit:GitPull" ], "Resource": "*", "Effect": "Allow" }, ``` 1. 選擇**檢閱政策**。輸入政策的名稱 (例如 **codecommit-gitpull**)，然後選擇 **Create policy (建立政策)**。 1. 返回您連接許可的頁面，重新整理政策清單，然後選取您剛建立的政策。選擇**連接政策**。 ## 管道錯誤：採用 CodeployToECS 動作的部署會傳回錯誤訊息：「嘗試從 <來源成品名稱> 讀取工作定義成品檔案時發生例外狀況」 **問題：** 任務定義檔案是 CodePipeline 透過 CodeDeploy 將動作部署至 Amazon ECS 的必要成品 (`CodeDeployToECS`動作）。部署動作中的成品 ZIP `CodeDeployToECS` 大小上限為 3 MB。找不到檔案或成品大小超過 3 MB 時，會傳回下列錯誤訊息： 嘗試從 <來源成品名稱> 讀取工作定義成品檔案時發生例外狀況 **可能的修正：**確定任務定義檔案包含為成品。如果檔案已存在， 會確定壓縮的大小小於 3 MB。 ## GitHub （透過 OAuth 應用程式） 來源動作：儲存庫清單會顯示不同的儲存庫 **問題：** 在 CodePipeline 主控台中成功授權 GitHub （透過 OAuth 應用程式） 動作後，您可以從 GitHub 儲存庫清單中選擇。如果清單不包含您預期看到的儲存庫，則可以對用於授權的帳戶進行故障診斷。 **可能的修正：**CodePipeline 主控台提供的儲存庫清單是以授權帳戶所屬的 GitHub 組織為基礎。確認您用來授權 GitHub 的帳戶是與建立儲存庫的 GitHub 組織相關聯的帳戶。 ## GitHub （透過 GitHub 應用程式） 來源動作：無法完成儲存庫的連線 **問題：** 由於 GitHub 儲存庫的連線使用 AWS Connector for GitHub，因此您需要儲存庫的組織擁有者許可或管理員許可，才能建立連線。 **可能的修正方式：**如需 GitHub 儲存庫許可層級的詳細資訊，請參閱 [https://docs.github.com/en/free-pro-team@latest/github/setting-up-and-managing-organizations-and-teams/permission-levels-for-an-organization](https://docs.github.com/en/free-pro-team@latest/github/setting-up-and-managing-organizations-and-teams/permission-levels-for-an-organization)。 ## Amazon S3 錯誤：CodePipeline 服務角色 取得 S3 儲存貯體 的 S3 存取遭拒 **問題：** 進行中時，CodePipeline 中的 CodeCommit 動作會檢查管道成品儲存貯體是否存在。如果動作沒有檢查的許可，Amazon S3 中會出現`AccessDenied`錯誤，且 CodePipeline 中會顯示下列錯誤訊息： CodePipeline 服務角色 "arn：aws：iam：：*AccountID*：role/service-role/*RoleID*" 正在取得 S3 儲存貯體 "*BucketName*" 的 S3 存取遭拒 動作的 CloudTrail 日誌也會記錄`AccessDenied`錯誤。 **可能的修正：**執行下列動作： + 對於連接至 CodePipeline 服務角色的政策，請將 `s3:ListBucket`新增至政策中的動作清單。如需檢視服務角色政策的說明，請參閱 [檢視管道 ARN 和服務角色 ARN （主控台）](pipelines-settings-console.md)。編輯服務角色的政策陳述式，如 中所述[將許可新增至 CodePipeline 服務角色](how-to-custom-role.md#how-to-update-role-new-services)。 + 對於連接至管道 Amazon S3 成品儲存貯體的資源型政策，也稱為*成品儲存貯體政策*，請新增 陳述式，以允許 CodePipeline 服務角色使用 `s3:ListBucket`許可。 **將政策新增至成品儲存貯體** 1. 遵循中的步驟[檢視管道 ARN 和服務角色 ARN （主控台）](pipelines-settings-console.md)，在管道**設定**頁面上選擇您的成品儲存貯體，然後在 Amazon S3 主控台中檢視它。 1. 選擇 **Permissions** (許可)。 1. 在 **Bucket policy (儲存貯體政策)** 下方，選擇 **Edit (編輯)**。 1. 在**政策**文字欄位中，輸入新的儲存貯體政策，或編輯現有政策，如下列範例所示。儲存貯體政策是 JSON 檔案，因此您必須輸入有效的 JSON。 下列範例顯示成品儲存貯體的儲存貯體政策陳述式，其中服務角色的範例角色 ID 為 *AROAEXAMPLEID*。 ``` { "Effect": "Allow", "Principal": "*", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::BucketName", "Condition": { "StringLike": { "aws:userid": "AROAEXAMPLEID:*" } } } ``` 下列範例顯示新增許可後的相同儲存貯體政策陳述式。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "SSEAndSSLPolicy", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket", "Condition": { "StringLike": { "aws:userid": "AROAEXAMPLEID:*" } } }, { "Sid": "DenyUnEncryptedObjectUploads", "Effect": "Deny", "Principal": "*", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*", "Condition": { "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" } } }, { "Sid": "DenyInsecureConnections", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*", "Condition": { "Bool": { "aws:SecureTransport": false } } } ] } ``` ------ 如需詳細資訊，請參閱[https://aws.amazon.com/blogs/security/writing-iam-policies-how-to-grant-access-to-an-amazon-s3-bucket/](https://aws.amazon.com/blogs/security/writing-iam-policies-how-to-grant-access-to-an-amazon-s3-bucket/)中的步驟。 1. 選擇**儲存**。 套用編輯的政策後，請依照中的步驟[手動啟動管道](pipelines-rerun-manually.md)手動重新執行管道。 ## 具有 Amazon S3、Amazon ECR 或 CodeCommit 來源的管道不會再自動啟動 **問題：** 對使用事件規則 (EventBridge 或 CloudWatch Events) 進行變更偵測之動作的組態設定進行變更後，主控台可能無法偵測來源觸發識別符相似且具有相同初始字元的變更。由於主控台不會建立新的事件規則，因此管道不會再自動啟動。 CodeCommit 參數名稱結尾的次要變更範例會將 CodeCommit 分支名稱變更為 `MyTestBranch-1` `MyTestBranch-2`。由於變更位於分支名稱的結尾，因此來源動作的事件規則可能不會更新或建立新來源設定的規則。 這適用於使用 CWE 事件進行變更偵測的來源動作，如下所示： **** | 來源動作 | 參數/觸發識別符 （主控台） | | --- | --- | | Amazon ECR | **儲存庫名稱** **映像標籤** | | Amazon S3 | **儲存貯體** **S3 物件金鑰** | | CodeCommit： | **儲存庫名稱** **分支名稱** | **可能的修正：** 執行以下任意一項： + 變更 CodeCommit/S3/ECR 組態設定，以便對參數值的起始部分進行變更。 **範例：**將您的分支名稱變更為 `release-branch` `2nd-release-branch`。避免名稱結尾的變更，例如 `release-branch-2`。 + 變更每個管道的 CodeCommit/S3/ECR 組態設定。 **範例：**將您的分支名稱變更為 `myRepo/myBranch` `myDeployRepo/myDeployBranch`。避免名稱結尾的變更，例如 `myRepo/myBranch2`。 + 使用 CLI 或 CloudFormation 來建立和更新變更偵測事件規則，而非主控台。如需為 S3 來源動作建立事件規則的說明，請參閱 [連線至使用 EventBridge 和 的 Amazon S3 來源動作 AWS CloudTrail](create-cloudtrail-S3-source.md)。如需為 Amazon ECR 動作建立事件規則的說明，請參閱 [Amazon ECR 來源動作和 EventBridge 資源](create-cwe-ecr-source.md)。如需為 CodeCommit 動作建立事件規則的說明，請參閱 [CodeCommit 來源動作和 EventBridge](triggering.md)。 在主控台中編輯動作組態之後，請接受由主控台建立的更新變更偵測資源。 ## 連線至 GitHub 時發生連線錯誤：「發生問題，請確定您的瀏覽器已啟用 Cookie」或「組織擁有者必須安裝 GitHub 應用程式」 **問題：** 若要在 CodePipeline 中建立 GitHub 來源動作的連線，您必須是 GitHub 組織擁有者。對於不在組織下的儲存庫，您必須是儲存庫擁有者。由組織擁有者以外的其他人員建立連線時，會針對組織擁有者建立請求，並顯示下列其中一個錯誤： 發生問題，請確保您的瀏覽器已啟用 cookie 或 組織擁有者必須安裝 GitHub 應用程式 **可能修正：**對於 GitHub 組織中的儲存庫，組織擁有者必須建立與 GitHub 儲存庫的連線。對於不在組織下的儲存庫，您必須是儲存庫擁有者。 ## 達到執行限制時，執行模式變更為 QUEUED 或 PARALLEL 模式的管道會失敗 **問題：**QUEUED 模式中管道的並行執行數目上限為 50 個執行。達到此限制時，管道會失敗，沒有狀態訊息。 **可能的修正：**編輯執行模式的管道定義時，請與其他編輯動作分開進行編輯。 如需 QUEUED 或 PARALLEL 執行模式的詳細資訊，請參閱 [CodePipeline 概念](concepts.md)。 ## 如果變更為 QUEUED 或 SUPERSEDED 模式時編輯過了 PARALLEL 模式的管道定義 **問題：**對於平行模式的管道，當將管道執行模式編輯為 QUEUED 或 SUPERSEDED 時，不會更新 PARALLEL 模式的管道定義。更新 PARALLEL 模式時的更新管道定義不會用於 SUPERSEDED 或 QUEUED 模式 **可能的修正：**對於平行模式下的管道，在將管道執行模式編輯為 QUEUED 或 SUPERSEDED 時，請避免同時更新管道定義。 如需 QUEUED 或 PARALLEL 執行模式的詳細資訊，請參閱 [CodePipeline 概念](concepts.md)。 ## 從 PARALLEL 模式變更的管道會顯示先前的執行模式 **問題：**對於處於 PARALLEL 模式的管道，當將管道執行模式編輯為 QUEUED 或 SUPERSEDED 時，管道狀態不會顯示更新的狀態為 PARALLEL。如果管道從 PARALLEL 變更為 QUEUED 或 SUPERSEDED，則 SUPERSEDED 或 QUEUED 模式中管道的狀態將是這些模式中的最後已知狀態。如果管道之前從未在該模式下執行，則狀態將為空。 **可能的修正：**對於平行模式的管道，在將管道執行模式編輯為 QUEUED 或 SUPERSEDED 時，請注意執行模式顯示不會顯示 PARALLEL 狀態。 如需 QUEUED 或 PARALLEL 執行模式的詳細資訊，請參閱 [CodePipeline 概念](concepts.md)。 ## 具有使用檔案路徑觸發篩選之連線的管道可能不會在分支建立時開始 **描述：**對於具有使用連線之來源動作的管道，例如 BitBucket 來源動作，您可以設定具有 Git 組態的觸發條件，允許您依檔案路徑篩選以啟動管道。在某些情況下，對於具有在檔案路徑上篩選之觸發條件的管道，當第一次建立具有檔案路徑篩選條件的分支時，管道可能不會啟動，因為這不允許 CodeConnections 連線解析變更的檔案。當觸發條件的 Git 組態設定為篩選檔案路徑時，在來源儲存庫中剛建立具有篩選條件的分支時，管道不會啟動。如需篩選檔案路徑的詳細資訊，請參閱 [使用程式碼推送或提取請求事件類型新增觸發](pipelines-filter.md)。 **結果：**例如，在分支 "B" 上具有檔案路徑篩選條件的 CodePipeline 中的管道不會在分支 "B" 建立時觸發。如果沒有檔案路徑篩選條件，管道仍會啟動。 ## 當達到檔案限制時，具有使用檔案路徑觸發篩選之連線的管道可能無法啟動 **描述：**對於具有使用連線之來源動作的管道，例如 BitBucket 來源動作，您可以設定具有 Git 組態的觸發條件，允許您依檔案路徑篩選以啟動管道。CodePipeline 最多擷取前 100 個檔案；因此，當觸發條件的 Git 組態設定為篩選檔案路徑時，如果有超過 100 個檔案，管道可能無法啟動。如需篩選檔案路徑的詳細資訊，請參閱 [使用程式碼推送或提取請求事件類型新增觸發](pipelines-filter.md)。 **結果：**例如，如果 diff 包含 150 個檔案，CodePipeline 會查看前 100 個檔案 （無特定順序），以檢查指定的檔案路徑篩選條件。如果符合檔案路徑篩選條件的檔案不在 CodePipeline 擷取的 100 個檔案中，則不會叫用管道。 ## PARALLEL 模式中的 CodeCommit 或 S3 來源修訂可能與 EventBridge 事件不相符 **描述：**對於 PARALLEL 模式中的管道執行，執行可能從最新的變更開始，例如 CodeCommit 儲存庫遞交，可能與 EventBridge 事件的變更不同。在某些情況下，當 CodePipeline 收到事件並啟動該執行時，在啟動管道的遞交或影像標籤之間可能會有一分秒，此時 CodePipeline （例如 CodeCommit 動作） 會複製 HEAD 遞交。 **結果：**對於具有 CodeCommit 或 S3 來源的 PARALLEL 模式管道，無論觸發管道執行的變更為何，來源動作一律會在啟動時複製 HEAD。例如，對於 PARALLEL 模式中的管道，推送遞交，這會啟動執行 1 的管道，而第二個管道執行會使用第二個遞交。 ## EC2 部署動作失敗並顯示錯誤訊息 `No such file` **描述：**在 EC2 部署動作解壓縮執行個體上目標目錄中的成品之後，動作會執行指令碼。如果指令碼位於目標目錄中，但動作無法執行指令碼，則該執行個體上的動作會失敗，而剩餘的執行個體會失敗部署。 類似下列錯誤訊息的錯誤會顯示在目標目錄為 `/home/ec2-user/deploy/`且來源儲存庫路徑為 的部署日誌中`myRepo/postScript.sh`。 + ``` Instance i-0145a2d3f3EXAMPLE is FAILED on event AFTER_DEPLOY, message: ----------ERROR------- chmod: cannot access '/home/ec2-user/deploy/myRepo/postScript.sh': No such file or directory /var/lib//_script.sh: line 2: /home/ec2-user/deploy/myRepo/postScript.sh: No such file or directory failed to run commands: exit status 127 ``` + ``` Executing commands on instances i-0145a2d3f3EXAMPLE, SSM command id , commands: chmod u+x /home/ec2-user/deploy/script.sh ----------ERROR-------: No such file or directory ``` **結果：**管道中的部署動作失敗。 **可能的修正：**若要疑難排解，請使用下列步驟。 1. 檢視日誌以驗證導致指令碼失敗的執行個體。 1. 將目錄 (`cd`) 變更為執行個體上的目標目錄。測試在執行個體上執行指令碼。 1. 在來源儲存庫中，編輯指令碼檔案以移除任何可能導致問題的註解或命令。 ## EKS 部署動作失敗並顯示`cluster unreachable`錯誤訊息 **描述：**EKS 部署動作執行後，動作會失敗並顯示`cluster unreachable`錯誤訊息。由於缺少許可，訊息顯示叢集上的存取問題。根據檔案類型 (Helm Chart 或 Kubernetes 資訊清單檔案），錯誤訊息會顯示如下。 + 對於使用 Helm Chart 的 EKS 部署動作，會顯示類似下列錯誤訊息的錯誤。 ``` error message: helm upgrade --install my-release test-chart --wait Error: Kubernetes cluster unreachable: the server has asked for the client to provide credentials ``` + 對於使用 Kubernetes 資訊清單檔案的 EKS 部署動作，會顯示類似下列錯誤訊息的錯誤。 ``` kubectl apply -f deployment.yaml Error: error validating "deployment.yaml": error validating data: failed to download openapi: the server has asked for the client to provide credentials ``` **結果：**管道中的部署動作失敗。 **可能的修正：**如果使用現有角色，則必須使用使用 EKS 部署動作所需的許可來更新 CodePipeline 服務角色。此外，若要允許 CodePipeline 服務角色存取叢集，您必須將存取項目新增至叢集，並為存取項目指定服務角色。 1. 確認 CodePipeline 服務角色具有 EKS 部署動作所需的許可。如需許可參考，請參閱 [服務角色政策許可](action-reference-EKS.md#action-reference-EKS-service-role)。 1. 將存取項目新增至您的叢集，並指定存取權的 CodePipeline 服務角色。如需範例，請參閱 [步驟 4：建立 CodePipeline 服務角色的存取項目](tutorials-eks-deploy.md#tutorials-eks-deploy-access-entry)。 ## 需要不同問題的協助嗎？ 嘗試其他資源： + 聯絡 [AWS 支援](https://aws.amazon.com/contact-us/)。 + 在 [CodePipeline 論壇](https://forums.aws.amazon.com/forum.jspa?forumID=197)中提出問題。 + [請求提高配額](https://console.aws.amazon.com/support/home#/case/create%3FissueType=service-limit-increase)。如需詳細資訊，請參閱[AWS CodePipeline 中的配額](limits.md)。 **注意** 最多可能需要兩週時間來處理提高配額的請求。