CodePipeline 문제 해결 - AWS CodePipeline
파이프라인 오류: AWS Elastic Beanstalk 으로 구성한 파이프라인이 오류 메시지를 반환했습니다. "Deployment failed. The provided role does not have sufficient permissions: Service:AmazonElasticLoadBalancing"배포 오류: "DescribeEvents" 권한이 누락되면 AWS Elastic Beanstalk 배포 작업으로 구성한 파이프라인이 실패하는 대신 멈춥니다.파이프라인 오류: 소스 작업이 권한이 부족하다는 메시지를 반환합니다. "CodeCommit 리포지토리 repository-name에 액세스할 수 없습니다. 파이프라인 IAM 역할에 있는 리포지토리 액세스 권한이 부족한지 확인하십시오."파이프라인 오류: Jenkins 빌드 또는 테스트 작업을 오래 지속했는데 자격 증명 또는 권한이 없어서 실패했습니다.파이프라인 오류: 다른 AWS 리전에서 생성된 버킷을 사용하여 한 AWS 리전에서 생성된 파이프라인은 “JobFailed” 코드와 함께 “InternalError”를 반환합니다.배포 오류: WAR 파일이 포함된 ZIP 파일이에 성공적으로 배포 AWS Elastic Beanstalk되었지만 애플리케이션 URL이 404를 찾을 수 없음 오류를 보고합니다.파이프라인 아티팩트 폴더 이름이 잘린 것처럼 보입니다.Bitbucket, GitHub, GitHub Enterprise Server 또는 GitLab.com 연결을 위한 CodeBuild GitClone 권한 추가CodeCommit 소스 작업에 대한 CodeBuild GitClone 권한 추가파이프라인 오류: CodeDeployToECS 작업을 통해 배포하면 “<소스 아티팩트 이름>에서 작업 정의 아티팩트 파일을 읽으려고 시도하는 동안 예외가 발생했습니다”라는 오류 메시지가 반환됩니다.GitHub(OAuth 앱 사용) 소스 작업: 리포지토리 목록에 서로 다른 리포지토리가 표시됨GitHub(GitHub 앱을 통해) 소스 작업: 리포지토리에 대한 연결을 완료할 수 없음Amazon S3 오류: CodePipeline 서비스 역할 <ARN>에서 S3 버킷<BucketName>에 대한 S3 액세스가 거부되었습니다.Amazon S3, Amazon ECR 또는 CodeCommit 소스를 사용하는 파이프라인은 더 이상 자동으로 시작되지 않음GitHub에 연결할 때 연결 오류 발생: "A problem occurred, make sure cookies are enabled in your browser" 또는 "An organization owner must install the GitHub app"실행 모드가 QUEUED 또는 PARALLEL 모드로 변경된 파이프라인은 실행 한도에 도달하면 실패합니다.QUEUED 또는 SUPERSEDED 모드로 변경할 때 편집하면 PARALLEL 모드의 파이프라인에 오래된 파이프라인 정의가 있습니다.PARALLEL 모드에서 변경된 파이프라인이 이전 실행 모드를 표시합니다.파일 경로별 트리거 필터링을 사용하는 연결이 있는 파이프라인은 브랜치 생성 시 시작되지 않을 수 있습니다.파일 경로별 트리거 필터링을 사용하는 연결이 있는 파이프라인은 파일 한도에 도달하면 시작되지 않을 수 있습니다.PARALLEL 모드의 CodeCommit 또는 S3 소스 개정이 EventBridge 이벤트와 일치하지 않을 수 있습니다.다른 문제에 도움이 필요하십니까?

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

CodePipeline 문제 해결

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

주제

파이프라인 오류: AWS Elastic Beanstalk 으로 구성한 파이프라인이 오류 메시지를 반환했습니다. "Deployment failed. The provided role does not have sufficient permissions: Service:AmazonElasticLoadBalancing"

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

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

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

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

배포 오류: "DescribeEvents" 권한이 누락되면 AWS Elastic Beanstalk 배포 작업으로 구성한 파이프라인이 실패하는 대신 멈춥니다.

문제: CodePipeline의 서비스 역할이 AWS Elastic Beanstalk를 사용하는 파이프라인에 대해 "elasticbeanstalk:DescribeEvents" 작업을 포함해야 합니다. 이 권한이 없으면 실패하거나 오류를 표시하지 않고 배포 AWS Elastic Beanstalk 작업이 중단됩니다. 서비스 역할에서이 작업이 누락된 경우 CodePipeline은 AWS Elastic Beanstalk 사용자를 대신하여에서 파이프라인 배포 단계를 실행할 권한이 없습니다.

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

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

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

문제: CodePipeline에 대한 서비스 역할에 CodeCommit 권한이 부족하고 CodeCommit 리포지토리 이용 지원을 추가한 2016년 4월 18일 이전에 만든 것 같습니다. 이 날짜 전에 서비스 역할을 만든 고객은 필요한 권한을 추가하도록 서비스 역할의 정책 설명을 변경해야 합니다.

수정 방법: CodePipeline 서비스 역할의 정책에 필요한 CodeCommit 권한을 추가합니다. 자세한 내용은 CodePipeline 서비스 역할에 권한 추가 단원을 참조하십시오.

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

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

수정 방법: Amazon EC2 인스턴스 역할 또는 IAM 사용자가 AWSCodePipelineCustomActionAccess 관리형 정책 혹은 동등한 권한으로 구성되었는지 확인합니다. 자세한 내용은 AWS 에 대한 관리형 정책 AWS CodePipeline 단원을 참조하십시오.

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

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

문제: 파이프라인과 버킷이 서로 다른 AWS 리전에 생성되면 Amazon S3 버킷에 저장된 아티팩트 다운로드가 실패합니다.

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

배포 오류: WAR 파일이 포함된 ZIP 파일이에 성공적으로 배포 AWS Elastic Beanstalk되었지만 애플리케이션 URL이 404를 찾을 수 없음 오류를 보고합니다.

문제: 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, 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. 파이프라인을 열고 소스 작업에서 (i) 아이콘을 클릭하여 파이프라인의 연결 ARN을 찾습니다. CodeBuild 서비스 역할 정책에 연결 ARN을 추가합니다.

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

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

  2. CodeBuild 서비스 역할을 찾으려면 파이프라인에 사용된 빌드 프로젝트를 열고 [빌드 세부 정보(Build details)] 탭으로 이동합니다.

  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 서비스 역할을 찾으려면 파이프라인에 사용된 빌드 프로젝트를 열고 [빌드 세부 정보(Build details)] 탭으로 이동합니다.

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

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

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

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

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

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

파이프라인 오류: CodeDeployToECS 작업을 통해 배포하면 “<소스 아티팩트 이름>에서 작업 정의 아티팩트 파일을 읽으려고 시도하는 동안 예외가 발생했습니다”라는 오류 메시지가 반환됩니다.

문제:

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

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

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

GitHub(OAuth 앱 사용) 소스 작업: 리포지토리 목록에 서로 다른 리포지토리가 표시됨

문제:

CodePipeline 콘솔에서 GitHub(OAuth 앱을 통해) 작업에 대한 권한 부여가 성공하면 GitHub 리포지토리 목록에서 선택할 수 있습니다. 목록에 표시될 것으로 예상했던 리포지토리가 포함되어 있지 않은 경우 권한 부여에 사용된 계정의 문제를 해결할 수 있습니다.

수정 방법: CodePipeline 콘솔에서 제공되는 리포지토리 목록은 승인된 계정이 속한 GitHub 조직을 기반으로 합니다. GitHub로 승인하기 위해 사용하는 계정이 리포지토리가 생성된 GitHub 조직과 연결된 계정인지 확인하세요.

GitHub(GitHub 앱을 통해) 소스 작업: 리포지토리에 대한 연결을 완료할 수 없음

문제:

GitHub 리포지토리에 대한 연결은 GitHub용 AWS 커넥터를 사용하기 때문에 연결을 생성하려면 리포지토리에 대한 조직 소유자 권한 또는 관리자 권한이 필요합니다.

가능한 해결 방법: 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 액세스가 거부되었습니다.

문제:

진행 중에 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 보기(콘솔) 단원을 참조하세요. CodePipeline 서비스 역할에 권한 추가에 설명된 대로 서비스 역할에 대한 정책 설명을 편집하세요.

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

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

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

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

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 또는를 사용하여 변경 감지 이벤트 규칙을 AWS CloudFormation 생성하고 업데이트합니다. S3 소스 작업에 대한 이벤트 규칙 생성에 대한 지침은 EventBridge 및를 사용하는 Amazon S3 소스 작업에 연결 AWS CloudTrail 단원을 참조하세요. Amazon ECR 작업에 대한 이벤트 규칙 생성에 대한 지침은 Amazon ECR 소스 작업 및 EventBridge 리소스 단원을 참조하세요. CodeCommit 작업에 대한 이벤트 규칙 생성에 대한 지침은 CodeCommit 소스 작업 및 EventBridge 단원을 참조하세요.

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

GitHub에 연결할 때 연결 오류 발생: "A problem occurred, make sure cookies are enabled in your browser" 또는 "An organization owner must install the GitHub app"

문제:

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

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

OR

An organization owner must install the GitHub app(조직 소유자가 GitHub 앱을 설치해야 합니다.)

가능한 수정: GitHub 조직의 리포지토리의 경우 조직 소유자가 GitHub 리포지토리에 대한 연결을 생성해야 합니다. 조직 소속이 아닌 리포지토리의 경우 리포지토리 소유자여야 합니다.

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

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

수정 방법: 실행 모드에 대한 파이프라인 정의를 편집할 때 다른 편집 작업과 별도로 편집합니다.

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

QUEUED 또는 SUPERSEDED 모드로 변경할 때 편집하면 PARALLEL 모드의 파이프라인에 오래된 파이프라인 정의가 있습니다.

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

수정 방법: 병렬 모드의 파이프라인의 경우 파이프라인 실행 모드를 QUEUED 또는 SUPERSEDED로 편집할 때 파이프라인 정의를 동시에 업데이트하지 않습니다.

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

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

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

수정 방법: 병렬 모드의 파이프라인의 경우 파이프라인 실행 모드를 QUEUED 또는 SUPERSEDED로 편집할 때 실행 모드 디스플레이에 PARALLEL 상태가 표시되지 않는다는 점을 유념하세요.

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

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

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

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

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

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

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

PARALLEL 모드의 CodeCommit 또는 S3 소스 개정이 EventBridge 이벤트와 일치하지 않을 수 있습니다.

설명: PARALLEL 모드에서 파이프라인 실행의 경우 CodeCommit 리포지토리 커밋과 같은 가장 최근 변경 사항으로 실행이 시작될 수 있으며, 이는 EventBridge 이벤트의 변경 사항과 동일하지 않을 수 있습니다. 파이프라인을 시작하는 커밋이나 이미지 태그 사이에 아주 짧은 순간의 간격이 있을 수 있는데, CodePipeline이 이벤트를 수신하고 해당 실행을 시작했을 때 다른 커밋이나 이미지 태그가 푸시된 경우(예: CodeCommit 작업) CodePipeline은 해당 순간에 HEAD 커밋을 복제합니다.

결과: CodeCommit 또는 S3 소스가 있는 PARALLEL 모드의 파이프라인의 경우 파이프라인 실행을 트리거한 변경 사항에 관계없이 소스 작업은 시작 시 항상 HEAD를 복제합니다. 예를 들어 PARALLEL 모드의 파이프라인의 경우 커밋이 푸시되어 실행 1을 위한 파이프라인이 시작되고 두 번째 파이프라인 실행은 두 번째 커밋을 사용합니다.

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

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