문제 해결 CodePipeline

다음은 AWS CodePipeline에서 일반적으로 발생하는 문제를 해결하는 데 유용한 정보입니다.

파이프라인 오류: AWS Elastic Beanstalk으로 구성한 파이프라인이 오류 메시지를 반환했습니다. "Deployment failed. 제공된 역할에 충분한 권한이 없습니다: 서비스:AmazonElasticLoadBalancing”

문제: 의 서비스 역할에 Elastic Load Balancing의 일부 작업을 포함하되 이에 국한되지 않는 충분한 권한이 없습니다. CodePipeline AWS Elastic Beanstalk 의 서비스 역할은 이 문제를 해결하기 위해 2015년 8월 6일에 CodePipeline 업데이트되었습니다. 이 날짜 전에 서비스 역할을 만든 고객은 필요한 권한을 추가하도록 서비스 역할의 정책 설명을 변경해야 합니다.

수정 방법: 가장 간단한 해결 방법은 CodePipeline 서비스 역할에 권한 추가에 자세히 설명된 대로 서비스 역할에 대한 정책 설명을 편집하는 것입니다.

편집한 정책을 적용한 후 수동으로 파이프라인 시작의 단계를 따라 Elastic Beanstalk를 사용하는 모든 파이프라인을 수동으로 반환하십시오.

보안 필요성에 따라 다른 방법으로도 권한을 변경할 수 있습니다.

배포 오류: AWS Elastic Beanstalk 배포 작업으로 구성된 파이프라인은 "DescribeEvents" 권한이 없는 경우 실패하지 않고 중지됩니다.

문제: 의 서비스 역할에는 사용하는 모든 파이프라인에 대한 "elasticbeanstalk:DescribeEvents" 작업이 CodePipeline 포함되어야 합니다. AWS Elastic Beanstalk 이 권한이 없으면 AWS Elastic Beanstalk 배포 작업이 실패하거나 오류가 발생하는 대신 작업이 멈춥니다. 이 작업이 서비스 역할에서 누락된 경우 사용자를 대신하여 파이프라인 배포 단계를 실행할 CodePipeline 권한이 없습니다. AWS Elastic Beanstalk

가능한 해결 방법: CodePipeline 서비스 역할을 검토하세요. "elasticbeanstalk:DescribeEvents" 작업이 누락된 경우 CodePipeline 서비스 역할에 권한 추가의 단계에 따라 IAM 콘솔에서 정책 편집 기능을 사용하여 작업을 추가합니다.

편집한 정책을 적용한 후 수동으로 파이프라인 시작의 단계를 따라 Elastic Beanstalk를 사용하는 모든 파이프라인을 수동으로 반환하십시오.

파이프라인 오류: 소스 작업이 권한 부족 메시지를 반환함: “ CodeCommit 리포지토리에 액세스할 수 없습니다repository-name. 파이프라인 IAM 역할에 있는 리포지토리 액세스 권한이 부족한지 확인하십시오."

문제: 의 서비스 역할에는 충분한 권한이 CodePipeline 없으며 2016년 4월 18일에 CodeCommit 리포지토리 사용에 대한 지원이 추가되기 전에 생성되었을 수 있습니다. CodeCommit 이 날짜 전에 서비스 역할을 만든 고객은 필요한 권한을 추가하도록 서비스 역할의 정책 설명을 변경해야 합니다.

가능한 해결 방법: CodePipeline 서비스 역할 정책에 필요한 CodeCommit 권한을 추가합니다. 자세한 설명은 CodePipeline 서비스 역할에 권한 추가 섹션을 참조하세요.

파이프라인 오류: Jenkins 빌드 또는 테스트 작업을 오래 지속했는데 자격 증명 또는 권한이 없어서 실패했습니다.

문제: Jenkins 서버가 Amazon EC2 인스턴스에 설치된 경우 필요한 권한을 가진 인스턴스 역할로 인스턴스가 생성되지 않았을 수 있습니다. CodePipeline 필수 IAM 역할이 없는 채로 만든 Jenkins 서버, 온프레미스 인스턴스, 혹은 Amazon EC2 인스턴스에서 IAM 사용자를 사용 중인 경우, IAM 사용자에게 필수 권한이 없거나 Jenkins 서버가 해당 서버에서 구성한 프로파일을 통해 그러한 자격 증명에 액세스할 수가 없습니다.

수정 방법: Amazon EC2 인스턴스 역할 또는 IAM 사용자가 AWSCodePipelineCustomActionAccess 관리형 정책 혹은 동등한 권한으로 구성되었는지 확인합니다. 자세한 설명은 AWS 관리형 정책은 다음과 같습니다. AWS CodePipeline 섹션을 참조하세요.

IAM 사용자를 사용 중인 경우 그 인스턴스에서 구성한 AWS 프로파일이 올바른 권한으로 구성한 IAM 사용자를 이용하는지 확인하십시오. Jenkins 간에 통합하고 Jenkins UI에 CodePipeline 직접 통합하도록 구성한 IAM 사용자 자격 증명을 제공해야 할 수도 있습니다. 이것은 권장되는 모범 사례는 아닙니다. 이 방법을 꼭 써야 한다면 Jenkins 서버의 보안을 확인하고 HTTP 대신 HTTPS를 사용하십시오.

파이프라인 오류: 다른 AWS 지역에서 생성된 버킷을 사용하여 한 AWS 지역에서 생성한 파이프라인은 코드 "“와 함께InternalError" “를 반환합니다. JobFailed

문제: 다른 AWS 리전에서 파이프라인과 버킷을 만든 경우 Amazon S3 버킷에 저장한 아티팩트를 다운로드할 때 오류가 발생합니다.

수정 방법: 아티팩트를 저장한 Amazon S3 버킷이 생성한 파이프라인과 동일한 AWS 리전에 있는지 확인합니다.

배포 오류: WAR 파일이 포함된 ZIP 파일을 AWS Elastic Beanstalk에 성공적으로 배포하였으나 애플리케이션 URL이 404 Not Found 오류를 보고합니다.

문제: WAR 파일이 AWS Elastic Beanstalk 환경에 성공적으로 배포되었으나 애플리케이션 URL이 404 Not Found 오류를 반환합니다.

수정 방법: 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, 엔터프라이즈 서버 또는 .com에 대한 연결 CodeBuild GitClone 권한을 추가합니다. GitHub GitHub GitLab

소스 작업과 작업에서 AWS CodeStar 연결을 사용하는 경우 입력 아티팩트를 빌드에 전달할 수 있는 두 가지 방법이 있습니다. CodeBuild

• 기본 방법: 소스 작업이 CodeBuild에서 다운로드하는 코드가 포함된 zip 파일을 생성합니다.

• Git 복제: 빌드 환경에서 소스 코드를 직접 다운로드할 수 있습니다.

  Git 복제 모드를 사용하면 작업 Git 리포지토리로서 소스 코드와 상호 작용할 수 있습니다. 이 모드를 사용하려면 CodeBuild 환경에 연결을 사용할 수 있는 권한을 부여해야 합니다.

CodeBuild 서비스 역할 정책에 권한을 추가하려면 고객 관리형 정책을 만들어 CodeBuild 서비스 역할에 연결해야 합니다. 다음 단계에서는 action 필드에 UseConnection 권한이 지정되고 Resource 필드에 연결 ARN이 지정된 정책을 만듭니다.

콘솔을 사용하여 권한을 추가하려면 UseConnection

1. 파이프라인을 열고 소스 작업에서 (i) 아이콘을 클릭하여 파이프라인의 연결 ARN을 찾습니다. 연결 ARN을 CodeBuild 서비스 역할 정책에 추가합니다.

   연결 ARN의 예는 다음과 같습니다.

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

2. CodeBuild 서비스 역할을 찾으려면 파이프라인에서 사용되는 빌드 프로젝트를 열고 빌드 세부정보 탭으로 이동하세요.

3. 서비스 역할 링크를 선택합니다. 그러면 연결에 대한 액세스 권한을 부여하는 새 정책을 추가할 수 있는 IAM 콘솔이 열립니다.

4. IAM 콘솔에서 Attach policies(정책 연결)를 선택하고 Create policy(정책 생성)를 선택합니다.

   다음 샘플 정책 템플릿을 사용합니다. 다음 예와 같이 Resource 필드에 연결 ARN을 추가합니다.

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

   JSON 탭에서 정책을 붙여 넣습니다.

5. 정책 검토를 선택합니다. 정책 이름(예: connection-permissions)을 입력한 후 Create policy(정책 생성)를 선택합니다.

6. 권한을 연결한 페이지로 돌아가서 정책 목록을 새로 고친 다음 방금 생성한 정책을 선택합니다. 정책 연결을 선택합니다.

   

CodeCommit소스 작업에 대한 CodeBuild GitClone 권한 추가

파이프라인에 CodeCommit 소스 작업이 있는 경우 두 가지 방법으로 입력 아티팩트를 빌드에 전달할 수 있습니다.

• 기본값 — 소스 액션은 CodeBuild 다운로드된 코드가 포함된 zip 파일을 생성합니다.

• 전체 복제 - 빌드 환경에서 소스 코드를 직접 다운로드할 수 있습니다.

  전체 복제 옵션을 사용하면 작업 Git 리포지토리로서 소스 코드와 상호 작용할 수 있습니다. 이 모드를 사용하려면 저장소에서 가져올 수 있는 CodeBuild 환경을 위한 권한을 추가해야 합니다.

CodeBuild 서비스 역할 정책에 권한을 추가하려면 서비스 역할에 연결하는 고객 관리형 정책을 만들어야 합니다 CodeBuild . 다음 단계는 action 필드의 codecommit:GitPull 권한을 지정하는 정책을 생성합니다.

콘솔을 사용하여 권한을 추가하려면 GitPull

1. CodeBuild 서비스 역할을 찾으려면 파이프라인에서 사용되는 빌드 프로젝트를 열고 빌드 세부정보 탭으로 이동하세요.

2. 서비스 역할 링크를 선택합니다. 그러면 리포지토리에 대한 액세스 권한을 부여하는 새 정책을 추가할 수 있는 IAM 콘솔이 열립니다.

3. IAM 콘솔에서 Attach policies(정책 연결)를 선택하고 Create policy(정책 생성)를 선택합니다.

4. JSON 탭에 다음 샘플 정책을 붙여넣습니다.

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

5. 정책 검토를 선택합니다. 정책 이름(예: codecommit-gitpull)을 입력한 후 Create policy(정책 생성)를 선택합니다.

6. 권한을 연결한 페이지로 돌아가서 정책 목록을 새로 고친 다음 방금 생성한 정책을 선택합니다. 정책 연결을 선택합니다.

<source artifact name>파이프라인 오류: CodeDeployTo ECS 작업을 사용한 디플로이먼트는 “다음에서 태스크 정의 아티팩트 파일을 읽으려고 시도하는 중 예외가 발생했습니다.” 라는 오류 메시지를 반환합니다.

문제:

작업 정의 파일은 CodeDeploy (작업) 을 통해 Amazon ECS로 CodePipeline 배포하는 작업에 필요한 아티팩트입니다CodeDeployToECS. CodeDeployToECS 배포 작업의 최대 아티팩트 ZIP 크기는 3MB입니다. 파일을 찾을 수 없거나 아티팩트 크기가 3MB를 초과하면 다음 오류 메시지가 반환됩니다.

<소스 아티팩트 이름>에서 작업 정의 아티팩트 파일을 읽으려고 시도하는 동안 예외가 발생했습니다

수정 방법: 태스크 정의 파일이 아티팩트로 포함되어 있는지 확인하세요. 파일이 이미 있는 경우 압축된 크기가 3MB 미만인지 확인하세요.

GitHub 버전 1 소스 작업: 리포지토리 목록에 다양한 리포지토리가 표시됩니다.

문제:

CodePipeline 콘솔에서 GitHub 버전 1 작업을 성공적으로 승인한 후에는 저장소 목록에서 원하는 작업을 선택할 수 있습니다 GitHub . 목록에 표시될 것으로 예상했던 리포지토리가 포함되어 있지 않은 경우 권한 부여에 사용된 계정의 문제를 해결할 수 있습니다.

가능한 해결 방법: CodePipeline 콘솔에 제공되는 리포지토리 목록은 승인된 계정이 GitHub 속한 조직을 기반으로 합니다. 권한 부여에 사용하는 계정이 저장소가 GitHub 생성된 GitHub 조직에 연결된 계정인지 확인하십시오.

GitHub 버전 2 소스 작업: 리포지토리에 대한 연결을 완료할 수 없습니다.

문제:

GitHub 리포지토리 연결에는 AWS 커넥터 형식이 사용되므로 연결을 만들려면 조직 소유자 권한 또는 리포지토리에 대한 GitHub 관리자 권한이 필요합니다.

가능한 해결 방법: GitHub 리포지토리의 권한 수준에 대한 자세한 내용은 https://docs.github.com/en/ free-pro-team @latest /github/ -/setting-up-and-managing-orgation을 참조하십시오. organizations-and-teams permission-levels-for-an

Amazon S3 오류: CodePipeline 서비스 역할이 <ARN>S3 버킷에 대한 S3 액세스가 거부되었습니다. < BucketName >

문제:

진행 중인 CodeCommit 작업은 파이프라인 아티팩트 버킷이 존재하는지 CodePipeline 확인합니다. 작업에 검사 권한이 없는 경우 Amazon S3에서 AccessDenied 오류가 발생하고 다음 오류 메시지가 에 표시됩니다 CodePipeline.

CodePipeline 서비스 역할 “arn:aws:iam:: 계정 ID:역할/서비스 역할/역할 ID “에서 S3 버킷에 대한 S3 액세스가 거부되었습니다.” BucketName

작업 로그에도 오류가 AccessDenied 기록됩니다. CloudTrail

수정 방법: 다음을 수행합니다.

• CodePipeline 서비스 역할에 연결된 정책의 경우 정책의 작업 s3:ListBucket 목록에 추가하십시오. 서비스 역할 정책을 보는 방법에 대한 지침은 파이프라인 ARN 및 서비스 역할 ARN 보기(콘솔) 단원을 참조하세요. CodePipeline 서비스 역할에 권한 추가에 설명된 대로 서비스 역할에 대한 정책 설명을 편집하세요.

• 파이프라인의 Amazon S3 아티팩트 버킷에 연결된 리소스 기반 정책 (아티팩트 버킷 정책이라고도 함) 의 경우 서비스 역할에서 s3:ListBucket 권한을 사용할 수 있도록 허용하는 설명을 추가하십시오. CodePipeline

  아티팩트 버킷에 정책을 추가하려면

  1. 파이프라인 ARN 및 서비스 역할 ARN 보기(콘솔)의 단계에 따라 파이프라인 설정 페이지에서 아티팩트 버킷을 선택한 다음 Amazon S3 콘솔에서 확인합니다.

  2. Permissions를 선택합니다.

  3. 버킷 정책에서 편집을 선택합니다.

  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. 저장을 선택합니다.

편집한 정책을 적용한 후 수동으로 파이프라인 시작의 단계를 따라 파이프라인을 수동으로 다시 실행하십시오.

Amazon S3, Amazon ECR 또는 CodeCommit 소스를 사용하는 파이프라인은 더 이상 자동으로 시작되지 않습니다.

문제:

변경 감지를 위해 이벤트 규칙 (EventBridge또는 CloudWatch 이벤트) 을 사용하는 작업의 구성 설정을 변경한 후, 콘솔은 소스 트리거 식별자가 비슷하고 첫 문자가 동일한 변경을 감지하지 못할 수 있습니다. 콘솔에서 새 이벤트 규칙을 생성하지 않으므로 파이프라인이 더 이상 자동으로 시작되지 않습니다.

의 파라미터 이름 끝에 있는 사소한 변경의 예로는 CodeCommit 분기 이름을 MyTestBranch-1 로 MyTestBranch-2 변경하는 경우를 CodeCommit 들 수 있습니다. 브랜치 이름 끝에 변경 사항이 적용되므로 소스 작업의 이벤트 규칙이 업데이트되지 않거나 새 소스 설정에 대한 규칙이 생성되지 않을 수 있습니다.

이는 다음과 같이 변경 감지에 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 소스 작업에 대한 이벤트 규칙 생성에 대한 지침은 Amazon S3 소스 액션 EventBridge 및 AWS CloudTrail 단원을 참조하세요. Amazon ECR 작업에 대한 이벤트 규칙 생성에 대한 지침은 Amazon ECR 소스 액션 및 리소스 EventBridge 단원을 참조하세요. 작업에 대한 이벤트 규칙 생성에 대한 지침은 을 참조하십시오. CodeCommit CodeCommit 소스 액션 및 EventBridge

콘솔에서 작업 구성을 편집한 후에는 콘솔에서 만든 업데이트된 변경 감지 리소스를 수락합니다.

연결 시 연결 오류 GitHub: “문제가 발생했습니다. 브라우저에 쿠키가 활성화되어 있는지 확인하세요.” 또는 “조직 소유자가 GitHub 앱을 설치해야 합니다.”

문제:

에서 GitHub CodePipeline 소스 작업을 위한 연결을 만들려면 GitHub 조직 소유자여야 합니다. 조직 소속이 아닌 리포지토리의 경우 리포지토리 소유자여야 합니다. 조직 소유자가 아닌 다른 사람이 연결을 생성하면 조직 소유자에 대한 요청이 생성되고 다음 오류 중 하나가 표시됩니다.

A problem occurred, make sure cookies are enabled in your browser(문제가 발생했습니다. 브라우저에서 쿠키가 활성화되어 있는지 확인하십시오.)

OR

조직 소유자가 GitHub 앱을 설치해야 합니다.

가능한 해결 방법: 조직 내 리포지토리의 경우 GitHub 조직 소유자가 리포지토리에 대한 연결을 만들어야 합니다. GitHub 조직 소속이 아닌 리포지토리의 경우 리포지토리 소유자여야 합니다.

리전에서 CloudFormationStackSet 또는 CloudFormationStackInstances 작업을 사용할 수 없는 경우 오류 발생

문제: 특정 지역에 존재한다고 해서 해당 지역에서 모든 작업을 수행할 수 있는 것은 아닙니다. CodePipeline 예를 들어, 파이프라인이 아프리카(케이프타운)와 같이 작업을 사용할 수 없는 리전에서 CloudFormationStackSet 작업을 실행하면 다음과 같은 오류가 표시됩니다.

InvalidActionDeclarationException: ActionType (Category: 'Deploy', Provider: 'CloudFormationStackSet', Owner: 'AWS, Version: '1') in action 'Deploy' is not available in region 'AF_SOUTH_1'

수정 방법: 작업을 사용할 수 있는 리전에서 작업을 사용하려면 다음 참고 사항을 참조하십시오.

참고

CloudFormationStackSet 및 CloudFormationStackInstances 작업은 아시아 태평양(홍콩), 유럽(취리히), 유럽(밀라노), 아프리카(케이프타운) 및 중동(바레인) 리전에서 사용할 수 없습니다. 사용 가능한 다른 작업을 참조하려면 제품 및 서비스 통합 CodePipeline을 참조하세요.

이러한 작업에 대한 자세한 내용은 AWS CloudFormation StackSets 섹션을 참조하세요.

실행 모드가 QUEUED 또는 PARALLEL 모드로 변경된 파이프라인은 실행 한도에 도달하면 실패합니다.

문제: QUEUED 모드에서 파이프라인의 최대 동시 실행 수는 50회입니다. 이 한도에 도달하면 상태 메시지 없이 파이프라인이 실패합니다.

가능한 해결 방법: 실행 모드에서 파이프라인 정의를 편집할 때 다른 편집 작업과 별도로 편집하십시오.

QUEUED 또는 PARALLEL 실행 모드에 대한 자세한 내용은 을 참조하십시오. CodePipeline 개념

PARALLEL 모드의 파이프라인은 QUEUED 또는 SUPERSEDED 모드로 변경할 때 편집하면 파이프라인 정의가 만료됩니다.

문제: 병렬 모드의 파이프라인에서 파이프라인 실행 모드를 QUEUED 또는 SUPERSEDED로 편집하면 PARALLEL 모드의 파이프라인 정의가 업데이트되지 않습니다. PARALLEL 모드를 업데이트할 때 업데이트된 파이프라인 정의는 대체 또는 대기 모드에서는 사용되지 않습니다.

가능한 해결 방법: 병렬 모드의 파이프라인의 경우 파이프라인 실행 모드를 QUEUED 또는 SUPERSEDED로 편집할 때 파이프라인 정의를 동시에 업데이트하지 마십시오.

QUEUED 또는 PARALLEL 실행 모드에 대한 자세한 내용은 을 참조하십시오. CodePipeline 개념

PARALLEL 모드에서 변경된 파이프라인은 이전 실행 모드를 표시합니다.

문제: PARALLEL 모드의 파이프라인에서 파이프라인 실행 모드를 QUEUED 또는 SUPERSEDED로 편집할 때 파이프라인 상태가 업데이트된 상태를 PARALLEL로 표시하지 않습니다. 파이프라인이 병렬에서 대기 또는 대체됨으로 변경된 경우 대체 또는 대기 모드의 파이프라인 상태는 두 모드 중 하나에서 마지막으로 알려진 상태가 됩니다. 이전에 해당 모드에서 파이프라인을 실행한 적이 없는 경우 상태는 비어 있게 됩니다.

가능한 해결 방법: 병렬 모드의 파이프라인에서 파이프라인 실행 모드를 QUEUED 또는 SUPERSEDED로 편집할 때 실행 모드 디스플레이에 PARALLEL 상태가 표시되지 않음에 유의하십시오.

대기 또는 병렬 실행 모드에 대한 자세한 내용은 을 참조하십시오. CodePipeline 개념

파일 경로를 기준으로 트리거 필터링을 사용하는 연결이 있는 파이프라인은 브랜치 생성 시 시작되지 않을 수 있습니다.

설명: 소스 작업과 같이 연결을 사용하는 소스 작업이 있는 파이프라인의 경우 파일 경로별로 필터링하여 파이프라인을 시작할 수 있는 Git 구성으로 트리거를 설정할 수 있습니다. BitBucket 파일 경로에서 필터링되는 트리거가 있는 파이프라인의 경우 파일 경로 필터가 있는 브랜치를 처음 만들 때 파이프라인이 시작되지 않는 경우가 있는데, 이렇게 하면 CodeConnections 연결이 변경된 파일을 확인할 수 없기 때문입니다. 트리거에 대한 Git 구성이 파일 경로를 기준으로 필터링하도록 설정된 경우, 필터가 포함된 브랜치가 소스 리포지토리에 방금 생성되면 파이프라인이 시작되지 않습니다. 파일 경로의 필터링에 대한 자세한 내용은 을 참조하십시오. 코드 푸시 또는 풀 요청 시 트리거 필터링

결과: 예를 들어 브랜치 “B”에 파일 경로 필터가 있는 파이프라인은 브랜치 “B”가 생성될 때 트리거되지 않습니다. CodePipeline 파일 경로 필터가 없는 경우에도 파이프라인은 계속 시작됩니다.

파일 경로를 기준으로 트리거 필터링을 사용하는 연결이 있는 파이프라인은 파일 제한에 도달하면 시작되지 않을 수 있습니다.

설명: 소스 작업과 같이 연결을 사용하는 소스 작업이 있는 파이프라인의 경우 파일 경로별로 필터링하여 파이프라인을 시작할 수 있는 Git 구성으로 트리거를 설정할 수 있습니다. BitBucket CodePipeline처음 100개의 파일을 검색합니다. 따라서 트리거에 대한 Git 구성이 파일 경로를 기준으로 필터링하도록 설정된 경우 파일이 100개가 넘는 경우 파이프라인이 시작되지 않을 수 있습니다. 파일 경로 필터링에 대한 자세한 내용은 을 참조하십시오. 코드 푸시 또는 풀 요청 시 트리거 필터링

결과: 예를 들어, diff에 150개의 파일이 포함된 경우 처음 100개의 파일 (특별한 순서 없음) 을 검토하여 지정된 파일 경로 필터와 비교합니다. CodePipeline 파일 경로 필터와 일치하는 파일이 에서 검색한 CodePipeline 100개 파일에 포함되지 않는 경우 파이프라인은 호출되지 않습니다.

다른 문제에 도움이 필요하십니까?

다른 리소스를 시도해 보십시오.

• AWS Support에 문의하세요.

• CodePipeline 포럼에 질문하십시오.

• 할당량 증가를 요청하십시오. 자세한 설명은 AWS CodePipeline의 할당량 섹션을 참조하세요.

  참고

  할당량 증대 요청을 처리하려면 최대 2주가 걸릴 수 있습니다.