문제 해결 CodePipeline - AWS CodePipeline
파이프라인 오류: AWS Elastic Beanstalk 으로 구성한 파이프라인이 오류 메시지를 반환했습니다. "Deployment failed. 제공된 역할에 충분한 권한이 없습니다: 서비스:AmazonElasticLoadBalancing”배포 오류: AWS Elastic Beanstalk 배포 작업으로 구성된 파이프라인은 "DescribeEvents" 권한이 없는 경우 실패하지 않고 중지됩니다.파이프라인 오류: 소스 작업이 권한 부족 메시지를 반환합니다. “ CodeCommit 리포지토리에 액세스할 수 없습니다repository-name. 파이프라인 IAM 역할에 리포지토리에 액세스할 수 있는 충분한 권한이 있는지 확인하세요.”파이프라인 오류: Jenkins 빌드 또는 테스트 작업을 오래 지속했는데 자격 증명 또는 권한이 없어서 실패했습니다.파이프라인 오류: 다른 AWS 지역에서 생성된 버킷을 사용하여 한 AWS 지역에서 생성된 파이프라인은 코드 "“와 함께InternalError" “를 반환합니다. JobFailed 배포 오류: ZIP 파일이 들어 있는 WAR 파일이 성공적으로 배포되었지만 애플리케이션에서 404 Not found 오류가 URL 보고되었습니다. AWS Elastic Beanstalk파이프라인 아티팩트 폴더 이름이 잘린 것처럼 보입니다.Bitbucket, 엔터프라이즈 서버 또는 .com에 대한 연결 CodeBuild GitClone 권한을 추가합니다. GitHub GitHub GitLab CodeCommit소스 작업에 대한 CodeBuild GitClone 권한 추가<source artifact name>파이프라인 오류: 작업이 포함된 배포에서 “ CodeDeployToECS작업 정의 아티팩트 파일을 읽으려고 시도하는 중 예외가 발생했습니다.” 라는 오류 메시지가 반환됩니다.GitHub 버전 1 소스 작업: 리포지토리 목록에 다양한 리포지토리가 표시됩니다.GitHub 버전 2 소스 작업: 리포지토리에 대한 연결을 완료할 수 없습니다.Amazon S3 오류: CodePipeline 서비스 역할 < ARN >에서 S3 버킷에 대한 S3 액세스가 거부되었습니다. < BucketName >Amazon S3ECR, Amazon 또는 CodeCommit 소스를 사용하는 파이프라인은 더 이상 자동으로 시작되지 않습니다.연결 시 연결 오류 GitHub: “문제가 발생했습니다. 브라우저에 쿠키가 활성화되어 있는지 확인하세요.” 또는 “조직 소유자가 GitHub 앱을 설치해야 합니다.”실행 모드가 QUEUED 또는 PARALLEL 모드로 변경된 파이프라인은 실행 한도에 도달하면 실패합니다.또는 PARALLEL 모드로 변경할 때 파이프라인을 편집하면 모드의 파이프라인은 오래된 파이프라인 정의를 갖게 됩니다. QUEUED SUPERSEDED 모드에서 변경된 파이프라인은 이전 실행 PARALLEL 모드를 표시합니다.파일 경로를 기준으로 트리거 필터링을 사용하는 연결이 있는 파이프라인은 브랜치 생성 시 시작되지 않을 수 있습니다.파일 경로를 기준으로 트리거 필터링을 사용하는 연결이 있는 파이프라인은 파일 제한에 도달하면 시작되지 않을 수 있습니다.CodeCommit 또는 PARALLEL 모드의 S3 소스 수정이 이벤트와 일치하지 않을 수 있습니다. EventBridge 다른 문제에 도움이 필요하십니까?

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

문제 해결 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"작업이 누락된 경우 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에 CodePipeline 직접 통합하기 위해 구성한 IAM 사용자 자격 증명을 제공해야 할 수도 있습니다. 이것은 권장되는 모범 사례는 아닙니다. 꼭 그렇게 해야 한다면 Jenkins 서버가 보안을 유지하고 대신 HTTPS 사용하는지 확인하세요. HTTP

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

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

가능한 해결 방법: 아티팩트가 저장된 Amazon S3 버킷이 생성한 파이프라인과 동일한 AWS 지역에 있는지 확인하십시오.

배포 오류: ZIP 파일이 들어 있는 WAR 파일이 성공적으로 배포되었지만 애플리케이션에서 404 Not found 오류가 URL 보고되었습니다. AWS Elastic Beanstalk

문제: WAR 파일이 AWS Elastic Beanstalk 환경에 성공적으로 배포되었지만 응용 프로그램에서 404 Not Found (404 Not Found) 오류가 URL 반환됩니다.

가능한 해결 방법: 파일의 압축을 풀 수는 있지만 ZIP WAR 파일에 포함된 파일의 압축은 풀 AWS Elastic Beanstalk 수 없습니다. ZIP 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, 엔터프라이즈 서버 또는 .com에 대한 연결 CodeBuild GitClone 권한을 추가합니다. GitHub GitHub GitLab

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

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

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

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

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

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

  1. 파이프라인 연결을 ARN 찾으려면 파이프라인을 열고 소스 액션의 (i) 아이콘을 클릭합니다. CodeBuild 서비스 역할 정책에 연결을 ARN 추가합니다.

    예제 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. 권한을 연결한 페이지로 돌아가서 정책 목록을 새로 고친 다음 방금 생성한 정책을 선택합니다. 정책 연결을 선택합니다.

    콘솔에서 정책을 연결하는 옵션을 보여주는 이미지

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

파이프라인에 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. 권한을 연결한 페이지로 돌아가서 정책 목록을 새로 고친 다음 방금 생성한 정책을 선택합니다. 정책 연결을 선택합니다.

<source artifact name>파이프라인 오류: 작업이 포함된 배포에서 “ CodeDeployToECS작업 정의 아티팩트 파일을 읽으려고 시도하는 중 예외가 발생했습니다.” 라는 오류 메시지가 반환됩니다.

문제:

작업 정의 파일은 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-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::AccountID:역할/서비스 역할/RoleID“S3 버킷에 대한 S3 액세스가 거부되었습니다.”BucketName"

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

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

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

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

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

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

    2. Permissions를 선택합니다.

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

    4. 정책 텍스트 필드에서 새 버킷 정책을 입력하거나 다음 예와 같이 기존 정책을 편집합니다. 버킷 정책은 JSON 파일이므로 valid를 입력해야 합니다. 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 S3ECR, Amazon 또는 CodeCommit 소스를 사용하는 파이프라인은 더 이상 자동으로 시작되지 않습니다.

문제:

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

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

이는 다음과 같이 변경 감지에 CWE 이벤트를 사용하는 소스 작업에 적용됩니다.

소스 작업 파라미터/트리거 식별자(콘솔)
아마존 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).

  • 콘솔 대신 or를 사용하여 변경 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회입니다. 이 한도에 도달하면 상태 메시지 없이 파이프라인이 실패합니다.

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

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

또는 PARALLEL 모드로 변경할 때 파이프라인을 편집하면 모드의 파이프라인은 오래된 파이프라인 정의를 갖게 됩니다. QUEUED SUPERSEDED

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

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

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

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

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

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

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

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

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

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

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

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

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

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

설명: PARALLEL 모드에서 파이프라인을 실행하는 경우 CodeCommit 리포지토리 커밋과 같은 가장 최근의 변경 사항으로 실행이 시작될 수 있으며, 이는 이벤트 변경 사항과 다를 수 있습니다. EventBridge 파이프라인을 시작하는 커밋이나 이미지 태그 사이에 찰나의 시간이 걸리는 경우, 이벤트를 CodePipeline 수신하고 실행을 시작하면 다른 커밋 또는 이미지 태그가 푸시되어 해당 시점에 HEAD 커밋을 복제합니다 CodePipeline (예: CodeCommit 액션).

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

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

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