문제 해결 CodePipeline - AWS CodePipeline
파이프라인 오류: AWS Elastic Beanstalk 으로 구성한 파이프라인이 오류 메시지를 반환했습니다. "Deployment failed. 제공된 역할에 충분한 권한이 없습니다. 서비스:AmazonElasticLoadBalancing'배포 오류: 배포 AWS Elastic Beanstalk 작업으로 구성된 파이프라인은 “DescribeEvents” 권한이 누락된 경우 실패 대신 중단됩니다.파이프라인 오류: 소스 작업은 불충분한 권한 메시지를 반환합니다. “리 CodeCommit 포지토리 에 액세스할 수 없습니다repository-name. 파이프라인 IAM 역할에 리포지토리에 액세스할 수 있는 충분한 권한이 있는지 확인합니다.”파이프라인 오류: Jenkins 빌드 또는 테스트 작업을 오래 지속했는데 자격 증명 또는 권한이 없어서 실패했습니다.파이프라인 오류: 다른 AWS 리전에서 생성된 버킷을 사용하여 한 AWS 리전에서 생성된 파이프라인은 코드 “InternalError”와 함께 “JobFailed”를 반환합니다.배포 오류: ZIP 파일이 포함된 WAR 파일이 에 성공적으로 배포 AWS Elastic Beanstalk되었지만 애플리케이션이 404를 찾을 수 없음 오류를 URL 보고합니다.파이프라인 아티팩트 폴더 이름이 잘린 것처럼 보입니다.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: “문제가 발생했습니다. 브라우저에서 쿠키가 활성화되어 있는지 확인하세요.” 또는 “조직 소유자가 GitHub 앱을 설치해야 합니다.”실행 모드가 로 변경QUEUED되거나 실행 한도에 도달하면 PARALLEL 모드가 실패하는 파이프라인QUEUED 또는 PARALLEL 모드로 변경할 때 편집된 경우 SUPERSEDED 모드의 파이프라인에 오래된 파이프라인 정의가 있습니다.PARALLEL 모드에서 변경된 파이프라인은 이전 실행 모드를 표시합니다.파일 경로별 트리거 필터링을 사용하는 연결이 있는 파이프라인은 브랜치 생성 시 시작되지 않을 수 있습니다.파일 경로별 트리거 필터링을 사용하는 연결이 있는 파이프라인은 파일 한도에 도달하면 시작되지 않을 수 있습니다.CodeCommit 또는 PARALLEL 모드의 S3 소스 개정이 EventBridge 이벤트와 일치하지 않을 수 있습니다.다른 문제에 도움이 필요하십니까?

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

문제 해결 CodePipeline

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

주제

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

문제: 의 서비스 역할에는 Elastic Load Balancing의 일부 작업을 AWS Elastic Beanstalk포함하되 이에 국한되지 않는 에 대한 충분한 권한이 CodePipeline 없습니다. 이 문제를 해결하기 위해 의 서비스 역할이 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" 작업이 누락된 경우 의 단계를 사용하여 IAM 콘솔의 정책 편집 기능을 사용하여 CodePipeline 서비스 역할에 권한 추가 추가합니다.

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

파이프라인 오류: 소스 작업은 불충분한 권한 메시지를 반환합니다. “리 CodeCommit 포지토리 에 액세스할 수 없습니다repository-name. 파이프라인 IAM 역할에 리포지토리에 액세스할 수 있는 충분한 권한이 있는지 확인합니다.”

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

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

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

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

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

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

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

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

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

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

문제: WAR 파일이 AWS Elastic Beanstalk 환경에 성공적으로 배포되었지만 애플리케이션이 404 찾을 수 없음 오류를 URL 반환합니다.

가능한 수정 사항: AWS Elastic Beanstalk ZIP 파일의 압축을 풀 수 있지만 ZIP 파일에 포함된 WAR 파일은 풀 수 없습니다. WAR 파일에 파일을 지정하는 대신 배포할 콘텐츠가 포함된 폴더를 buildspec.yml 지정합니다. 예:

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

  3. IAM 콘솔에서 정책 연결 을 선택한 다음 정책 생성 을 선택합니다.

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

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

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

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

파이프라인 오류: CodeDeployToECS 작업이 포함된 배포는 '<source artifact name>에서 태스크 정의 아티팩트 파일을 읽으려고 시도하는 동안 예외'라는 오류 메시지를 반환합니다.

문제:

작업 정의 파일은 CodeDeploy (작업)을 ECS 통해 Amazon에 작업을 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-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:role/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. 버킷 정책에서 편집을 선택합니다.

    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 브랜치 이름을 MyTestBranch-1로 변경하는 것이 CodeCommit 있습니다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 작업에 대한 이벤트 규칙 생성에 대한 지침은 섹션을 참조하세요 아마존 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 리포지토리에 대한 연결을 생성해야 합니다. 조직 소속이 아닌 리포지토리의 경우 리포지토리 소유자여야 합니다.

실행 모드가 로 변경QUEUED되거나 실행 한도에 도달하면 PARALLEL 모드가 실패하는 파이프라인

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

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

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

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

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

가능한 수정 사항: 병렬 모드의 파이프라인의 경우 파이프라인 실행 모드를 QUEUED 또는 로 편집할 때 파이프라인 정의를 동시에 업데이트SUPERSEDED하지 마세요.

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

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

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

가능한 수정 사항: 병렬 모드의 파이프라인의 경우 파이프라인 실행 모드를 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밋을 복제합니다.

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

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

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