故障診斷 CodePipeline - AWS CodePipeline
管道錯誤：使用 AWS Elastic Beanstalk ​ 設定的管道傳回錯誤訊息：「部署失敗。提供的角色沒有足夠的許可：Service：AmazonElasticLoadBalancing"部署錯誤：如果缺少「DescribeEvents」許可，則設定了 AWS Elastic Beanstalk 部署動作的管道會暫停，而不是失敗管道錯誤：來源動作會傳回許可不足訊息：「無法存取 CodeCommit 儲存庫 repository-name。確定管道IAM角色具有足夠的許可來存取儲存庫。"管道錯誤：Jenkins 建置或測試動作在一段長時間的執行後，因為缺乏登入資料或許可而失敗。管道錯誤：使用在另一個 AWS 區域中建立的儲存貯體，在某個 AWS 區域中建立的管道會傳回具有代碼 "InternalError" 的 "JobFailed"部署錯誤：包含WAR檔案ZIP的檔案已成功部署到 AWS Elastic Beanstalk，但應用程式URL回報找不到 404 錯誤管道成品資料夾名稱似乎被截斷了新增 Bitbucket、 GitHub GitHub Enterprise Server 或 GitLab.com 連線的 CodeBuild GitClone 許可新增來源動作的 CodeBuild GitClone CodeCommit許可管道錯誤：具有 CodeDeployToECS動作的部署會傳回錯誤訊息：「嘗試讀取任務定義成品檔案時例外：<source artifact name>」GitHub 第 1 版來源動作：儲存庫清單顯示不同的儲存庫GitHub 第 2 版來源動作：無法完成儲存庫的連線Amazon S3 錯誤： CodePipeline 服務角色 <ARN> 正在取得 S3 儲存貯體 <BucketName> 的 S3 存取遭拒Amazon S3、Amazon ECR或 CodeCommit來源的管道不再自動啟動連線至 時發生連線錯誤 GitHub：「發生問題，請確定已在瀏覽器中啟用 Cookie」或「組織擁有者必須安裝 GitHub 應用程式」執行模式變更為 QUEUED或 PARALLEL 模式的管道在達到執行限制時失敗如果在變更為 QUEUED或 PARALLEL 模式時編輯過時的管道定義，則SUPERSEDED處於 模式的管道具有過時的管道定義從 PARALLEL 模式變更的管道會顯示先前的執行模式具有使用檔案路徑觸發篩選之連線的管道可能無法從分支建立開始當達到檔案限制時，具有使用檔案路徑觸發篩選之連線的管道可能無法啟動CodeCommit 或 PARALLEL 模式中的 S3 來源修訂版可能與 EventBridge 事件不符 需要不同問題的協助嗎？

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

故障診斷 CodePipeline

以下資訊可能有助於診斷 AWS CodePipeline內的常見問題。

主題

管道錯誤：使用 AWS Elastic Beanstalk ​ 設定的管道傳回錯誤訊息：「部署失敗。提供的角色沒有足夠的許可：Service：AmazonElasticLoadBalancing"

問題： 的服務角色 CodePipeline 沒有足夠的 許可， AWS Elastic Beanstalk包括但不限於 Elastic Load Balancing 中的某些操作。的服務角色 CodePipeline 已於 2015 年 8 月 6 日更新，以解決此問題。在此日期前建立其服務角色的客戶，必須修改服務角色的政策陳述式以新增必要許可。

可能的修正：最簡單的解決方案是編輯服務角色的政策陳述式，詳述於將許可新增至 CodePipeline 服務角色中。

套用編輯的政策後，請依照 中的步驟手動啟動管道手動重新執行任何使用 Elastic Beanstalk 的管道。

根據您的安全性需求，也可以使用其他方式修改許可。

部署錯誤：如果缺少「DescribeEvents」許可，則設定了 AWS Elastic Beanstalk 部署動作的管道會暫停，而不是失敗

問題： 的服務角色 CodePipeline 必須包含使用 的任何管道"elasticbeanstalk:DescribeEvents"的動作 AWS Elastic Beanstalk。如果沒有此許可， AWS Elastic Beanstalk 部署動作會停止，而不會失敗或指示錯誤。如果您的服務角色缺少此動作，則 CodePipeline 沒有 AWS Elastic Beanstalk 代表您在 中執行管道部署階段的許可。

可能的修正：檢閱您的 CodePipeline 服務角色。如果動作遺失，請使用 中的步驟將許可新增至 CodePipeline 服務角色，使用IAM主控台中的編輯政策功能新增"elasticbeanstalk:DescribeEvents"該動作。

套用編輯的政策後，請依照 中的步驟手動啟動管道手動重新執行任何使用 Elastic Beanstalk 的管道。

管道錯誤：來源動作會傳回許可不足訊息：「無法存取 CodeCommit 儲存庫 repository-name。確定管道IAM角色具有足夠的許可來存取儲存庫。"

問題：在 2016 年 4 月 18 日新增支援使用 CodeCommit儲存庫之前， 的服務角色 CodePipeline 沒有足夠的許可， CodeCommit 可能已建立 。在此日期前建立其服務角色的客戶，必須修改服務角色的政策陳述式以新增必要許可。

可能的修正：將 的必要許可 CodeCommit 新增至 CodePipeline 服務角色的政策。如需詳細資訊，請參閱將許可新增至 CodePipeline 服務角色。

管道錯誤：Jenkins 建置或測試動作在一段長時間的執行後，因為缺乏登入資料或許可而失敗。

問題：如果 Jenkins 伺服器安裝在 Amazon EC2執行個體上，則執行個體可能尚未使用具有 所需許可的執行個體角色建立 CodePipeline。如果您在 Jenkins 伺服器、內部部署執行個體或在沒有必要IAM角色的情況下建立的 Amazon EC2執行個體上使用IAM使用者，則該IAM使用者可能沒有所需的許可，或 Jenkins 伺服器無法透過伺服器上設定的設定檔存取這些憑證。

可能的修正：確定 Amazon EC2執行個體角色或IAM使用者已設定 AWSCodePipelineCustomActionAccess 受管政策或具有同等許可。如需詳細資訊，請參閱AWS 的 受管政策 AWS CodePipeline。

如果您使用的是IAM使用者，請確定在執行個體上設定的 AWS 設定檔使用具有正確許可設定IAM的使用者。您可能必須提供您為 Jenkins 與 CodePipeline 直接整合而設定IAM的使用者憑證到 Jenkins UI。這不是建議的最佳實務。如果您必須這樣做，請確定 Jenkins 伺服器已受到保護並使用 HTTPS，而不是 HTTP。

管道錯誤：使用在另一個 AWS 區域中建立的儲存貯體，在某個 AWS 區域中建立的管道會傳回具有代碼 "InternalError" 的 "JobFailed"

問題：如果管道和儲存貯體在不同 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

如需範例，請參閱 CodeBuild 的AWS Elastic Beanstalk 範例。

管道成品資料夾名稱似乎被截斷了

問題：當您在 中檢視管道成品名稱時 CodePipeline，名稱似乎已被截斷。這可能使名稱看起來都很相似或似乎不再包含整個管道名稱。

說明： CodePipeline 截斷成品名稱，以確保在為作業工作者 CodePipeline 產生臨時憑證時，完整的 Amazon S3 路徑不會超過政策大小限制。

即使成品名稱似乎被截斷，以不受截斷名稱之成品影響的方式 CodePipeline 映射到成品儲存貯體。該管道可以正常運作。這不是資料夾或成品的問題。管道名稱有 100 個字元的限制。雖然成品資料夾名稱看起來可能變短了，對管道來說仍然是唯一的。

新增 Bitbucket、 GitHub GitHub Enterprise Server 或 GitLab.com 連線的 CodeBuild GitClone 許可

當您在來源動作和 CodeBuild 動作中使用 AWS CodeStar 連線時，有兩種方式可以將輸入成品傳遞至建置：

  • 預設：來源動作會產生包含下載程式碼 CodeBuild的 zip 檔案。

  • Git 複製：來源程式碼可以直接下載到建置環境。

    Git 複製模式可讓您將原始程式碼當成工作中 Git 儲存庫來互動。若要使用此模式，您必須授予 CodeBuild 環境許可才能使用連線。

若要將許可新增至 CodeBuild 服務角色政策，您可以建立連接至 CodeBuild 服務角色的客戶受管政策。下列步驟會建立政策，其中在 action 欄位中指定UseConnection許可，並在 Resource 欄位中ARN指定連線。

使用主控台新增 UseConnection 許可

  1. 若要尋找管道ARN的連線，請開啟管道，然後按一下來源動作上的 （i） 圖示。您可以將連線新增至ARN CodeBuild 服務角色政策。

    連線範例ARN為：

    arn:aws:codeconnections:eu-central-1:123456789123:connection/sample-1908-4932-9ecc-2ddacee15095

  2. 若要尋找您的 CodeBuild 服務角色，請開啟管道中使用的建置專案，然後導覽至建置詳細資訊索引標籤。

  3. 選擇 Service role (服務角色) 連結。這會開啟IAM主控台，您可以在其中新增可授予連線存取權的新政策。

  4. 在IAM主控台中，選擇連接政策 ，然後選擇建立政策 。

    使用下列政策範本範例。在 ARN 欄位中新增您的連線Resource，如本範例所示：

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "codestar-connections:UseConnection",
            "Resource": "insert connection ARN here"
        }
    ]
}

    在 JSON索引標籤上貼上您的政策。

  5. 選擇檢閱政策。輸入政策的名稱 (例如 connection-permissions)，然後選擇 Create policy (建立政策)。

  6. 返回您連接許可的頁面，重新整理政策清單，然後選取您剛建立的政策。選擇連接政策。

    顯示在主控台中連接政策選項的圖片

新增來源動作的 CodeBuild GitClone CodeCommit許可

當您的管道具有 CodeCommit 來源動作時，有兩種方式可以將輸入成品傳遞至建置：

  • 預設 – 來源動作會產生包含 CodeBuild 下載程式碼的 zip 檔案。

  • 完全複製 – 原始程式碼可以直接下載至建置環境。

    完整複製選項可讓您以工作 Git 儲存庫身分與原始程式碼互動。若要使用此模式，您必須為要 CodeBuild從儲存庫提取的環境新增許可。

若要將許可新增至 CodeBuild 服務角色政策，您可以建立連接至 CodeBuild 服務角色的客戶受管政策。下列步驟會建立政策，在 action 欄位中指定codecommit:GitPull許可。

使用主控台新增 GitPull 許可

  1. 若要尋找您的 CodeBuild 服務角色，請開啟管道中使用的建置專案，然後導覽至建置詳細資訊索引標籤。

  2. 選擇 Service role (服務角色) 連結。這會開啟IAM主控台，您可以在其中新增可授予儲存庫存取權的新政策。

  3. 在IAM主控台中，選擇連接政策 ，然後選擇建立政策 。

  4. 在 JSON索引標籤上，貼上下列範例政策。

    {
    "Action": [
        "codecommit:GitPull"
    ],
    "Resource": "*",
    "Effect": "Allow"
},

  5. 選擇檢閱政策。輸入政策的名稱 (例如 codecommit-gitpull)，然後選擇 Create policy (建立政策)。

  6. 返回您連接許可的頁面，重新整理政策清單，然後選取您剛建立的政策。選擇連接政策。

管道錯誤：具有 CodeDeployToECS動作的部署會傳回錯誤訊息：「嘗試讀取任務定義成品檔案時例外：<source artifact name>」

問題：

任務定義檔案是ECS透過 CodePipeline CodeDeploy （CodeDeployToECS動作） 部署動作至 Amazon 所需的成品。CodeDeployToECS 部署動作中的成品ZIP大小上限為 3 MB。找不到檔案或成品大小超過 3 MB 時，會傳回下列錯誤訊息：

嘗試從 <來源成品名稱> 讀取工作定義成品檔案時發生例外狀況

可能的修正：確定任務定義檔案包含為成品。如果檔案已存在，請確定壓縮的大小小於 3 MB。

GitHub 第 1 版來源動作：儲存庫清單顯示不同的儲存庫

問題：

成功授權 CodePipeline 主控台中的第 1 GitHub 版動作後，您可以從 GitHub 儲存庫清單中選擇。如果清單不包含您預期看到的儲存庫，則可以對用於授權的帳戶進行故障診斷。

可能的修正： CodePipeline 主控台中提供的儲存庫清單是以授權帳戶所屬 GitHub 的組織為基礎。確認您用來授權 的帳戶 GitHub 是與建立儲存庫 GitHub 的組織相關聯的帳戶。

GitHub 第 2 版來源動作：無法完成儲存庫的連線

問題：

由於與 GitHub 儲存庫的連線使用適用於 的 AWS Connector GitHub，因此您需要儲存庫的組織擁有者許可或管理員許可才能建立連線。

可能的修正：如需 GitHub 儲存庫許可層級的相關資訊，請參閱 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 服務角色 <ARN> 正在取得 S3 儲存貯體 <BucketName> 的 S3 存取遭拒

問題：

進行中時， 中的 CodeCommit 動作會 CodePipeline 檢查管道成品儲存貯體是否存在。如果動作沒有檢查的許可，Amazon S3 中會出現AccessDenied錯誤，且 中會顯示下列錯誤訊息 CodePipeline：

CodePipeline 服務角色 "arn：aws：iam：：AccountID：角色/service-role/RoleID" 正在取得 S3 儲存貯體的 S3 存取遭拒"BucketName"

動作的 CloudTrail 日誌也會記錄AccessDenied錯誤。

可能的修正：執行下列動作：

  • 對於附加至 CodePipeline 服務角色的政策，請s3:ListBucket新增至政策中的動作清單。如需檢視服務角色政策的指示，請參閱 檢視管道ARN和服務角色 ARN（主控台）。編輯服務角色的政策陳述式，如 中所述將許可新增至 CodePipeline 服務角色。

  • 對於連接至管道 Amazon S3 成品儲存貯體的資源型政策，也稱為成品儲存貯體政策 ，請新增 陳述式，以允許 CodePipeline 服務角色使用s3:ListBucket許可。

    若要將政策新增至成品儲存貯體

    1. 請依照 中的步驟檢視管道ARN和服務角色 ARN（主控台），在管道設定頁面上選擇成品儲存貯體，然後在 Amazon S3 主控台中檢視。

    2. 選擇 Permissions (許可)。

    3. 在 Bucket policy (儲存貯體政策) 下方，選擇 Edit (編輯)。

    4. 在政策文字欄位中，輸入新的儲存貯體政策，或編輯現有政策，如下列範例所示。儲存貯體政策是 JSON 檔案，因此您必須輸入有效的 JSON。

      下列範例顯示成品儲存貯體的儲存貯體政策陳述式，其中服務角色的範例角色 ID 為 AROAEXAMPLEID.

      {
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:ListBucket",
    "Resource": "arn:aws:s3:::BucketName",
    "Condition": {
        "StringLike": {
            "aws:userid": "AROAEXAMPLEID:*"
        }
    }
}

      下列範例顯示新增許可後的相同儲存貯體政策陳述式。

      {
    "Version": "2012-10-17",
    "Id": "SSEAndSSLPolicy",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::codepipeline-us-east-2-1234567890",
            "Condition": {
                "StringLike": {
                    "aws:userid": "AROAEXAMPLEID:*"
                }
            }
        },
        {
            "Sid": "DenyUnEncryptedObjectUploads",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::codepipeline-us-east-2-1234567890/*",
            "Condition": {
                "StringNotEquals": {
                    "s3:x-amz-server-side-encryption": "aws:kms"
                }
            }
        },
        {
            "Sid": "DenyInsecureConnections",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::codepipeline-us-east-2-1234567890/*",
            "Condition": {
                "Bool": {
                    "aws:SecureTransport": false
                }
            }
        }
    ]
}

      如需詳細資訊，請參閱https://aws.amazon.com/blogs/security/writing-iam-policies-how-to-grant-access-to-an-amazon-s3-bucket/中的步驟。

    5. 選擇 Save (儲存)。

套用編輯的政策後，請依照 中的步驟手動啟動管道手動重新執行管道。

Amazon S3、Amazon ECR或 CodeCommit來源的管道不再自動啟動

問題：

變更使用事件規則 （EventBridge 或 CloudWatch 事件） 進行變更偵測的動作的組態設定後，主控台可能無法偵測到來源觸發識別碼相似且具有相同初始字元的變更。由於主控台不會建立新的事件規則，因此管道不再自動啟動。

的參數名稱結尾的次要變更範例， 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或 AWS CloudFormation 來建立和更新變更偵測事件規則，而不是主控台。如需為 S3 來源動作建立事件規則的指示，請參閱 連接到使用 EventBridge 和的 Amazon S3 來源動作 AWS CloudTrail。如需為 Amazon ECR動作建立事件規則的指示，請參閱 Amazon ECR 源動作和 EventBridge 資源。如需為 CodeCommit 動作建立事件規則的指示，請參閱 CodeCommit 來源動作和 EventBridge。

在主控台中編輯動作組態後，請接受由主控台建立的更新變更偵測資源。

連線至 時發生連線錯誤 GitHub：「發生問題，請確定已在瀏覽器中啟用 Cookie」或「組織擁有者必須安裝 GitHub 應用程式」

問題：

若要在 中建立 GitHub 來源動作的連線 CodePipeline，您必須是 GitHub組織擁有者。對於不在組織下的儲存庫，您必須是儲存庫擁有者。由組織擁有者以外的其他人員建立連線時，會針對組織擁有者建立請求，並顯示下列其中一個錯誤：

發生問題，請確保您的瀏覽器已啟用 cookie

或

組織擁有者必須安裝 GitHub 應用程式

可能的修正：對於組織中的 GitHub儲存庫，組織擁有者必須建立與 GitHub 儲存庫的連線。對於不在組織下的儲存庫，您必須是儲存庫擁有者。

執行模式變更為 QUEUED或 PARALLEL 模式的管道在達到執行限制時失敗

問題：QUEUED模式中管道的並行執行數目上限為 50 個執行。達到此限制時，管道會失敗，而沒有狀態訊息。

可能的修正：編輯執行模式的管道定義時，請與其他編輯動作分開進行編輯。

如需 QUEUED或 PARALLEL 執行模式的詳細資訊，請參閱 CodePipeline 概念。

如果在變更為 QUEUED或 PARALLEL 模式時編輯過時的管道定義，則SUPERSEDED處於 模式的管道具有過時的管道定義

問題：對於平行模式的管道，在將管道執行模式編輯為 QUEUED或 時SUPERSEDED，不會更新PARALLEL模式的管道定義。更新PARALLEL模式時更新的管道定義不會用於 SUPERSEDED或 QUEUED 模式

可能的修正：對於平行模式的管道，在將管道執行模式編輯為 QUEUED或 時SUPERSEDED，避免同時更新管道定義。

如需 QUEUED或 PARALLEL 執行模式的詳細資訊，請參閱 CodePipeline 概念。

從 PARALLEL 模式變更的管道會顯示先前的執行模式

問題：對於處於 PARALLEL 模式的管道，當將管道執行模式編輯為 QUEUED或 時SUPERSEDED，管道狀態不會顯示更新的狀態為 PARALLEL。如果管道從 PARALLEL 變更為 QUEUED或 SUPERSEDED，則 SUPERSEDED或 QUEUED模式中管道的狀態將是這些模式中的最後已知狀態。如果管道之前從未在該模式下執行，則狀態將為空。

可能的修正：對於平行模式的管道，當將管道執行模式編輯為 QUEUED或 時SUPERSEDED，請注意執行模式顯示不會顯示 PARALLEL 狀態。

如需 QUEUED或 PARALLEL 執行模式的詳細資訊，請參閱 CodePipeline 概念。

具有使用檔案路徑觸發篩選之連線的管道可能無法從分支建立開始

說明：對於具有來源動作的管道，例如 BitBucket 來源動作，您可以使用 Git 組態設定觸發條件，以依檔案路徑篩選以啟動管道。在某些情況下，對於具有在檔案路徑上篩選的觸發條件的管道，當第一次建立具有檔案路徑篩選條件的分支時，管道可能不會啟動，因為這不允許 CodeConnections 連線解析變更的檔案。當觸發程序的 Git 組態設定為在檔案路徑上進行篩選時，在來源儲存庫中剛建立具有篩選條件的分支時，管道不會啟動，如需檔案路徑篩選的詳細資訊，請參閱 程式碼推送或提取請求時篩選觸發條件。

結果：例如，在分支 "B" 上具有檔案路徑篩選條件 CodePipeline 的管道，在建立分支 "B" 時不會觸發。如果沒有檔案路徑篩選條件，管道仍會啟動。

當達到檔案限制時，具有使用檔案路徑觸發篩選之連線的管道可能無法啟動

說明：對於具有使用連線之來源動作的管道，例如 BitBucket 來源動作，您可以設定具有 Git 組態的觸發條件，可讓您依檔案路徑篩選以啟動管道。 CodePipeline 最多擷取前 100 個檔案；因此，當觸發條件的 Git 組態設定為篩選檔案路徑時，如果有超過 100 個檔案，則可能無法啟動管道。如需檔案路徑篩選的詳細資訊，請參閱 程式碼推送或提取請求時篩選觸發條件。

結果：例如，如果 diff 包含 150 個檔案， CodePipeline 會查看前 100 個檔案 （沒有特定順序），以檢查指定的檔案路徑篩選條件。如果符合檔案路徑篩選條件的檔案不在 擷取的 100 個檔案之間 CodePipeline，則不會叫用管道。

CodeCommit 或 PARALLEL 模式中的 S3 來源修訂版可能與 EventBridge 事件不符

描述：對於在 PARALLEL 模式下的管道執行，執行可能會從最新的變更開始，例如 CodeCommit 儲存庫遞交，這些變更可能與 EventBridge 事件的變更不同。在某些情況下，當 收到事件並啟動該執行時 CodePipeline，另一個遞交或影像標籤已被推送時 CodePipeline （例如， CodeCommit 動作） 會在啟動管道的HEAD遞交或影像標籤之間進行分割。

結果：對於具有 CodeCommit或 S3 來源的 PARALLEL 模式中的管道，無論觸發管道執行的變更為何，來源動作一律會在啟動HEAD時複製 。例如，對於處於 PARALLEL 模式的管道，會推送遞交，這會啟動執行 1 的管道，而第二個管道執行會使用第二個遞交。

需要不同問題的協助嗎？

嘗試其他資源：