CodePipeline에서 유효한 작업 유형 및 공급자 CodePipeline의 파이프라인 및 단계 구조 요구 사항 CodePipeline의 작업 구조 요구 사항

CodePipeline 파이프라인 구조 참조

기본적으로 AWS CodePipeline에서 성공적으로 생성한 파이프라인에는 유효한 구조가 있습니다. 하지만 수동으로 JSON 파일을 생성하거나 편집하여 파이프라인을 생성하거나 AWS CLI에서 파이프라인을 업데이트하면 예기치 않게 유효하지 않은 구조가 형성될 수 있습니다. 다음 참조 정보는 파이프라인 구조의 요구 사항과 문제 해결 방법을 더 잘 이해하는 데 도움이 될 수 있습니다. AWS CodePipeline의 할당량 단원에서 모든 파이프라인에 적용되는 제약 조건을 참조하십시오.

CodePipeline에서 유효한 작업 유형 및 공급자

파이프라인 구조 형식은 파이프라인에서 작업 및 스테이지 빌드에 사용됩니다. 작업 유형은 작업 범주 및 공급자 유형으로 구성됩니다.

다음은 CodePipeline에 유효한 작업 범주입니다.

소스
빌드
테스트
배포
승인
Invoke

각 작업 범주에는 지정된 공급자 집합이 있습니다. Amazon S3와 같은 각 작업 공급자에는 파이프라인 구조의 작업 범주에 있는 Provider 필드에서 사용해야 하는 공급자 이름(예: S3)이 있습니다.

파이프라인 구조의 작업 범주 섹션에 있는 Owner 필드에는 세 가지 유효한 값( AWS, ThirdParty 및 Custom)이 있습니다.

작업 공급자의 공급자 이름과 소유자 정보를 찾으려면 작업 구조 참조 또는 각 작업 유형에 대한 입력 및 출력 아티팩트 수 단원을 참조하십시오.

이 표에는 작업 유형별로 유효한 공급자가 나열되어 있습니다.

참고

Bitbucket Cloud, GitHub, GitHub Enterprise Server 또는 GitLab.com 작업에 대해서는 CodeStarSourceConnection 비트버킷 클라우드 GitHub, GitHub 엔터프라이즈 서버, GitLab .com 및 GitLab 자체 관리 작업용 작업 참조 주제를 참조하세요.

작업 유형별로 유효한 작업 공급자
작업 범주	유효한 작업 공급자	작업 참조
소스	Amazon S3	Amazon S3 소스 작업
	Amazon ECR	Amazon ECR
	CodeCommit	CodeCommit
	CodeStarSourceConnection(Bitbucket Cloud, GitHub, GitHub Enterprise Server 또는 GitLab.com 작업용)	CodeStarSourceConnection 비트버킷 클라우드 GitHub, GitHub 엔터프라이즈 서버, GitLab .com 및 GitLab 자체 관리 작업용
빌드	CodeBuild	AWS CodeBuild
	사용자 지정 CloudBees	각 작업 유형에 대한 입력 및 출력 아티팩트 수
	사용자 지정 Jenkins	각 작업 유형에 대한 입력 및 출력 아티팩트 수
	사용자 지정 TeamCity	각 작업 유형에 대한 입력 및 출력 아티팩트 수
테스트	CodeBuild	AWS CodeBuild
	AWS Device Farm	각 작업 유형에 대한 입력 및 출력 아티팩트 수
	ThirdParty GhostInspector	각 작업 유형에 대한 입력 및 출력 아티팩트 수
	사용자 지정 Jenkins	각 작업 유형에 대한 입력 및 출력 아티팩트 수
	ThirdParty Micro Focus StormRunner 로드	각 작업 유형에 대한 입력 및 출력 아티팩트 수
	ThirdParty Nouvola	각 작업 유형에 대한 입력 및 출력 아티팩트 수
배포	Amazon S3	Amazon S3 배포 작업
	AWS CloudFormation	AWS CloudFormation
	AWS CloudFormation StackSets(`CloudFormationStackSet` 및 `CloudFormationStackInstances` 작업 포함)	AWS CloudFormation StackSets
	CodeDeploy	각 작업 유형에 대한 입력 및 출력 아티팩트 수
	Amazon ECS	각 작업 유형에 대한 입력 및 출력 아티팩트 수
	Amazon ECS(블루/그린)(`CodeDeployToECS` 작업)	각 작업 유형에 대한 입력 및 출력 아티팩트 수
	Elastic Beanstalk	각 작업 유형에 대한 입력 및 출력 아티팩트 수
	AWS AppConfig	AWS AppConfig
	AWS OpsWorks	각 작업 유형에 대한 입력 및 출력 아티팩트 수
	서비스 카탈로그	각 작업 유형에 대한 입력 및 출력 아티팩트 수
	Amazon Alexa	각 작업 유형에 대한 입력 및 출력 아티팩트 수
	사용자 지정 XebiaLabs	각 작업 유형에 대한 입력 및 출력 아티팩트 수
승인	수동	각 작업 유형에 대한 입력 및 출력 아티팩트 수
Invoke	AWS Lambda	AWS Lambda
Invoke	AWS Step Functions	AWS Step Functions

CodePipeline의 일부 작업 유형은 일부 AWS 리전에서만 사용 가능합니다. AWS 리전에서 작업 유형은 사용 가능하지만 해당 작업 유형에 대한 AWS 공급자는 사용 가능하지 않습니다.

각 작업 공급자에 대한 자세한 내용은 CodePipeline 작업 유형과의 통합 항목을 참조하십시오.

다음 섹션에서는 공급자 정보와 각 동작 유형의 구성 속성에 대한 예제를 제공합니다.

CodePipeline의 파이프라인 및 단계 구조 요구 사항

두 단계 파이프라인은 다음과 같은 기본 구조를 갖습니다.


{
    "roleArn": "An IAM ARN for a service role, such as arn:aws:iam::80398EXAMPLE:role/CodePipeline_Service_Role",
    "stages": [
        {
            "name": "SourceStageName",
            "actions": [
            ... See CodePipeline의 작업 구조 요구 사항 ...
            ]
        },
        {
            "name": "NextStageName",
            "actions": [
            ... See CodePipeline의 작업 구조 요구 사항 ...
            ]
        }
    ],
    "artifactStore": {
        "type": "S3",
        "location": "The name of the Amazon S3 bucket automatically generated for you the first time you create a pipeline
            using the console, such as codepipeline-us-east-2-1234567890, or any Amazon S3 bucket you provision for this purpose"
    },
    "name": "YourPipelineName",
    "version": 1
}

파이프라인 구조는 다음 요구 사항을 충족해야 합니다.

파이프라인에는 두 개 이상의 단계가 포함되어야 합니다.
파이프라인의 첫 단계에는 하나 이상의 소스 작업이 포함되어야 합니다. 소스 작업만 포함할 수 있습니다.
파이프라인의 첫 단계만 소스 작업을 포함할 수 있습니다.
각 파이프라인에서 하나 이상의 단계에 소스 작업이 아닌 작업이 포함되어야 합니다.
파이프라인 내의 모든 단계 이름은 고유해야 합니다.
단계 이름은 CodePipeline 콘솔에서 편집할 수 없습니다. AWS CLI를 사용하여 단계 이름을 편집하는 경우, 그리고 단계에 하나 이상의 보안 파라미터가 있는 작업이 포함되는 경우(OAuth 토큰 등) 이러한 보안 파라미터의 값은 유지되지 않습니다. 파라미터의 값을 수동으로 입력하고(AWS CLI가 반환한 JSON에 네 개의 별표로 마스킹됨) JSON 구조에 포함시켜야 합니다.
artifactStore 필드에는 파이프라인의 위치 및 결과물 버킷 유형과 동일한 AWS 리전의 모든 작업이 포함되어 있습니다. 파이프라인과 다른 리전에 작업을 추가하는 경우 작업이 실행되는 각 AWS 리전의 아티팩트 버킷을 나열하는 데 artifactStores 매핑이 사용됩니다. 파이프라인을 생성하거나 편집할 때 파이프라인 리전에 아티팩트 버킷이 있어야 하며 작업을 실행하려는 리전마다 아티팩트 버킷 하나가 있어야 합니다.

다음 예제는 artifactStores 파라미터를 사용하는 교차 리전 작업이 있는 파이프라인의 기본 구조를 보여줍니다.
```
    "pipeline": {
        "name": "YourPipelineName",
        "roleArn": "CodePipeline_Service_Role",
        "artifactStores": {
            "us-east-1": {
                "type": "S3",
                "location": "S3 artifact bucket name, such as codepipeline-us-east-1-1234567890"
            },
            "us-west-2": {
                "type": "S3",
                "location": "S3 artifact bucket name, such as codepipeline-us-west-2-1234567890"
            }
        },
        "stages": [
            {

...
```
파이프라인 메타데이터 필드는 파이프라인 구조와 다르며 편집할 수 없습니다. 파이프라인을 업데이트하면 updated 메타데이터 필드의 데이터가 자동으로 변경됩니다.
파이프라인을 편집하거나 업데이트할 때 파이프라인 이름은 변경할 수 없습니다.

참고
기존 파이프라인의 이름을 바꾸려는 경우 CLI get-pipeline 명령을 사용하여 파이프라인의 구조를 포함하는 JSON 파일을 빌드하면 됩니다. 그런 다음 CLI create-pipeline 명령을 사용하여 해당 구조가 포함된 새 파이프라인을 생성하고 새 이름을 지정하면 됩니다.

파이프라인의 버전 번호는 파이프라인을 업데이트할 때마다 자동으로 생성되고 업데이트됩니다.

CodePipeline의 작업 구조 요구 사항

작업의 개략적 구조는 다음과 같습니다.


[
                {
                   "inputArtifacts": [
                        An input artifact structure, if supported for the action category
                    ],
                   "name": "ActionName",
                   "region": "Region", 
                   "namespace": "source_namespace", 
                   "actionTypeId": {
                        "category": "An action category",
                        "owner": "AWS",
                        "version": "1"
                        "provider": "A provider type for the action category",
                   },
                   "outputArtifacts": [
                        An output artifact structure, if supported for the action category
                   ],
                   "configuration": {
                        Configuration details appropriate to the provider type
                   },
                   "runOrder": A positive integer that indicates the run order within the stage,
                }
            ]

공급자 유형에 적합한 예제 configuration 세부 정보 목록을 보려면 공급자 유형별 구성 세부 정보 항목을 참조하십시오.

작업 구조는 다음 요구 사항을 충족해야 합니다.

단계 내의 모든 작업 이름은 고유해야 합니다.
작업의 입력 아티팩트는 이전 작업에서 선언된 출력 아티팩트와 정확히 일치해야 합니다. 예를 들어 이전 작업에 다음 선언이 포함되고,
```
"outputArtifacts": [
    {
    "MyApp"
    }
],
```
다른 출력 아티팩트가 없는 경우 다음 작업의 입력 아티팩트는 이와 같아야 합니다.
```
"inputArtifacts": [
    {
    "MyApp"
    }
],
```
같은 단계에 있든 다음 단계에 있든 모든 작업에 적용되지만, 입력 아티팩트가 출력 아티팩트를 제공했던 작업으로부터 순서상 반드시 다음 단계일 필요는 없습니다. 동시 작업이 서로 다른 출력 아티팩트 번들을 선언할 수 있으며, 그러면 차례로 다른 다음 작업에서 이를 사용하게 됩니다.
파이프라인에서 출력 아티팩트 이름은 고유해야 합니다. 예를 들어 한 파이프라인에 "MyApp"이라는 출력 아티팩트가 있는 작업과 "MyBuiltApp"이라는 출력 아티팩트가 있는 또 하나의 작업이 포함될 수 있습니다. 하지만 한 파이프라인에 "MyApp"이라는 출력 아티팩트가 있는 두 개의 작업이 포함될 수 없습니다.
교차 리전 작업은 Region 필드를 사용하여 작업이 생성될 AWS 리전을 지정합니다. 이 작업에서 생성된 AWS 리소스는 region 필드에 제공된 것과 동일한 리전에 생성됩니다. 다음 작업 유형에는 교차 리전 작업을 생성할 수 없습니다.
- 소스 작업
- 타사 공급자 기준 작업
- 사용자 지정 공급자 기준 작업
작업은 변수로 구성할 수 있습니다. namespace 필드를 사용하여 실행 변수에 대한 네임스페이스 및 변수 정보를 설정합니다. 실행 변수 및 작업 출력 변수에 대한 참조 정보는 Variables 단원을 참조하십시오.
현재 지원되는 모든 작업 유형에서 유일하게 유효한 소유자 문자열은 AWS, ThirdParty 또는 Custom입니다. 자세한 내용은 CodePipeline API 참조를 참조하세요.
작업의 기본 runOrder 값은 1입니다. 이 값은 양의 정수(자연수)여야 합니다. 분수, 소수, 음수나 0을 사용할 수 없습니다. 작업 순서를 지정하려면 첫 번째 작업에 가장 작은 숫자를, 나머지 작업에는 각각의 순서에 따라 더 큰 숫자를 사용합니다. 동시 작업을 지정하려면 동시에 실행할 각 작업에 동일한 정수를 사용합니다. 콘솔에서 실행하려는 단계의 수준에서 작업 그룹 추가를 선택하여 작업의 직렬 시퀀스를 지정하거나 작업 추가를 선택하여 병렬 시퀀스를 지정할 수 있습니다. 작업 그룹이란 동일한 수준에 있는 하나 이상의 동작으로 구성된 실행 순서를 말합니다.

예를 들어 한 단계에서 세 가지 작업이 순서에 따라 실행되도록 하려면 첫 번째 작업의 runOrder 값으로 1을, 두 번째 작업의 runOrder 값으로 2를, 세 번째 작업의 runOrder 값으로 3을 부여합니다. 하지만 두 번째와 세 번째 작업이 동시에 실행되도록 하려면 첫 번째 작업의 runOrder 값으로 1을, 두 번째와 세 번째 작업의 runOrder 값으로 2를 부여합니다.

참고
연속 작업의 숫자 지정을 정확히 순서대로 할 필요는 없습니다. 예를 들어 순서대로 해야 하는 3개 작업이 있고 두 번째 작업을 제거하기로 한 경우, 세 번째 작업의 runOrder 값에 숫자를 다시 지정할 필요는 없습니다. 작업 (3)의 runOrder 값이 첫 번째 작업 (1)의 runOrder 값보다 크기 때문에 단계에서 첫 번째 작업 후 순서대로 실행됩니다.

배포 위치로 Amazon S3 버킷을 사용할 때 객체 키도 지정합니다. 객체 키는 파일 이름(객체) 또는 접두사(폴더 경로)와 파일 이름의 조합일 수 있습니다. 변수를 사용하여 파이프라인에서 사용할 위치 이름을 지정할 수 있습니다. Amazon S3 배포 작업은 Amazon S3 객체 키에서 다음 변수 사용을 지원합니다.

Amazon S3에서 변수 사용
datetime	js-application/{datetime}.zip	다음 형식의 UTC 타임스탬프: <YYYY>-<MM>-DD>_<HH>-<MM>-<SS> 예제: js-application/2019-01-10_07-39-57.zip
uuid	js-application/{uuid}.zip	UUID는 다른 식별자와 다른 것으로 보장되는 전 세계적으로 고유한 식별자입니다. UUID는 <8자리>-<4자리>-4자리>-<4자리>-<12자리>의 형식(16진수 형식의 모든 숫자)으로 되어 있습니다. 예제: js-application/54a60075-b96a-4bf3-9013-db3a9EXAMPLE.zip

Amazon S3에서 변수 사용

변수

콘솔 입력의 예

출력

datetime

js-application/{datetime}.zip

다음 형식의 UTC 타임스탬프: <YYYY>-<MM>-DD>_<HH>-<MM>-<SS>

예제:

js-application/2019-01-10_07-39-57.zip

uuid

js-application/{uuid}.zip

UUID는 다른 식별자와 다른 것으로 보장되는 전 세계적으로 고유한 식별자입니다. UUID는 <8자리>-<4자리>-4자리>-<4자리>-<12자리>의 형식(16진수 형식의 모든 숫자)으로 되어 있습니다.

예제:

js-application/54a60075-b96a-4bf3-9013-db3a9EXAMPLE.zip

CodePipeline에 대해 유효한 actionTypeId 범주:
- Source
- Build
- Approval
- Deploy
- Test
- Invoke
일부 공급자 유형 및 구성 옵션이 여기에 제공되어 있습니다.
작업 범주별로 유효한 공급자 유형은 범주에 따라 다릅니다. 예를 들어 소스 작업 유형의 경우 유효한 공급자 유형은 S3, GitHub, CodeCommit 또는 Amazon ECR입니다. 이 예제는 S3 공급자가 있는 소스 작업의 구조를 보여줍니다.
```
"actionTypeId": {
  "category": "Source",
  "owner": "AWS",
  "version": "1",
  "provider": "S3"},
```

모든 작업에는 유효한 작업 구성이 있어야 하며 이는 해당 작업의 공급자 유형에 따라 다릅니다. 다음 표에는 유효한 공급자 유형별로 필요한 작업 구성 요소가 수록되어 있습니다.

공급자 유형별 작업 구성 속성
공급자 이름	작업 유형의 공급자 이름	구성 속성	필수 속성인가?
Amazon S3(배포 작업 공급자)	Amazon S3 배포 작업 파라미터에 관련된 예제를 포함하여 자세한 내용을 보려면 Amazon S3 배포 작업 단원을 참조하십시오.
Amazon S3(소스 작업 공급자)	Amazon S3 소스 작업 파라미터에 관련된 예제를 포함하여 자세한 내용을 보려면 Amazon S3 소스 작업 단원을 참조하십시오.
Amazon ECR	Amazon ECR 파라미터에 관련된 예제를 포함하여 자세한 내용을 보려면 Amazon ECR 단원을 참조하십시오.
CodeCommit	CodeCommit 파라미터에 관련된 예제를 포함하여 자세한 내용을 보려면 CodeCommit 단원을 참조하십시오.
GitHub	GitHub 파라미터에 관련된 예제를 포함하여 자세한 내용을 보려면 GitHub 버전 1 소스 액션 구조 참조 단원을 참조하십시오.
AWS CloudFormation	AWS CloudFormation 파라미터에 관련된 예제를 포함하여 자세한 내용을 보려면 AWS CloudFormation 단원을 참조하십시오.
CodeBuild	CodeBuild 파라미터에 관련된 추가 설명 및 예제를 보려면 AWS CodeBuild 단원을 참조하십시오.
CodeDeploy	CodeDeploy 파라미터에 관련된 추가 설명 및 예제를 보려면 AWS CodeDeploy 단원을 참조하십시오.
AWS Device Farm	AWS Device Farm 파라미터에 관련된 추가 설명 및 예제를 보려면 AWS Device Farm 단원을 참조하십시오.
AWS Elastic Beanstalk	`ElasticBeanstalk`	`ApplicationName`	필수
AWS Elastic Beanstalk	`ElasticBeanstalk`	`EnvironmentName`	필수
AWS Lambda	AWS Lambda 파라미터에 관련된 예제를 포함하여 자세한 내용을 보려면 AWS Lambda 단원을 참조하십시오.
AWS OpsWorks Stacks	`OpsWorks`	`Stack`	필수
		`Layer`	선택
		`App`	필수
Amazon ECS	Amazon ECS 파라미터에 관련된 추가 설명 및 예제를 보려면 Amazon Elastic Container Service 단원을 참조하십시오.
Amazon ECS 및 CodeDeploy(블루/그린)	Amazon ECS 및 CodeDeploy 블루/그린 파라미터에 관련된 추가 설명 및 예제를 보려면 Amazon Elastic Container Service 및 CodeDeploy 블루-그린 단원을 참조하십시오.
서비스 카탈로그	`ServiceCatalog`	`TemplateFilePath`	필수
		`ProductVersionName`	필수
		`ProductType`	필수
		`ProductVersionDescription`	선택
		`ProductId`	필수
Alexa Skills Kit	`AlexaSkillsKit`	`ClientId`	필수
		`ClientSecret`	필수
		`RefreshToken`	필수
		`SkillId`	필수
Jenkins	Jenkins에 대해 CodePipeline 플러그인에 제공한 작업 이름(예: `MyJenkinsProviderName`)	`ProjectName`	필수
수동 승인	`Manual`	`CustomData`	선택
		`ExternalEntityLink`	선택
		`NotificationArn`	선택

주제

각 작업 유형에 대한 입력 및 출력 아티팩트 수
PollForSourceChanges 파라미터의 기본 설정
공급자 유형별 구성 세부 정보

각 작업 유형에 대한 입력 및 출력 아티팩트 수

작업 유형에 따라 입력 및 출력 아티팩트의 숫자는 다음과 같을 수 있습니다.

작업 유형 아티팩트 제약
Owner	작업 유형	Provider	유효한 입력 아티팩트 숫자	유효한 출력 아티팩트 숫자
`AWS`	소스	Amazon S3	0	1
`AWS`	소스	CodeCommit	0	1
`AWS`	소스	Amazon ECR	0	1
`ThirdParty`	소스	GitHub	0	1
`AWS`	빌드	CodeBuild	1 ~ 5	0~5
`AWS`	테스트	CodeBuild	1 ~ 5	0~5
`AWS`	테스트	AWS Device Farm	1	0
`AWS`	승인	수동	0	0
`AWS`	배포	Amazon S3	1	0
`AWS`	배포	AWS CloudFormation	0 ~ 10	0 ~ 1
`AWS`	배포	CodeDeploy	1	0
`AWS`	배포	AWS Elastic Beanstalk	1	0
`AWS`	배포	AWS OpsWorks Stacks	1	0
`AWS`	배포	Amazon ECS	1	0
`AWS`	배포	서비스 카탈로그	1	0
`AWS`	Invoke	AWS Lambda	0 ~ 5	0~5
`ThirdParty`	배포	Alexa Skills Kit	1 ~ 2	0
`Custom`	빌드	Jenkins	0 ~ 5	0~5
`Custom`	테스트	Jenkins	0 ~ 5	0~5
`Custom`	지원되는 모든 범주	사용자 정의 작업에 지정된 대로	0 ~ 5	0~5

PollForSourceChanges 파라미터의 기본 설정

PollForSourceChanges 파라미터 기본값은 파이프라인 생성에 사용된 방법에 따라 결정됩니다(아래 표 참조). 많은 경우 PollForSourceChanges 파라미터 기본값은 true이며 비활성화되어야 합니다.

PollForSourceChanges 파라미터를 기본값이 true일 때 다음을 수행해야 합니다.

PollForSourceChanges 파라미터를 JSON 파일 또는 AWS CloudFormation 템플릿에 추가합니다.
변경 감지 리소스(CloudWatch Events 규칙(해당 시))를 생성합니다.
PollForSourceChanges 파라미터를 false로 설정합니다.

참고
CloudWatch 이벤트 규칙 또는 webhook을 생성하는 경우 파라미터를 false로 설정하여 파이프라인을 한 번 이상 트리거하지 않도록 해야 합니다.

PollForSourceChanges 파라미터는 Amazon ECR 소스 작업에 사용하지 않아야 합니다.

PollForSourceChanges 파라미터 기본값
소스	생성 방법	예제 '구성' JSON 구조 출력
CodeCommit	파이프라인은 콘솔로 생성되며 변경 감지 리소스는 콘솔에 의해 생성됩니다. 이 파라미터는 파이프라인 구조 출력에 표시되고 기본값은 `false`입니다.	`BranchName": "main", "PollForSourceChanges": "false", "RepositoryName": "my-repo"`
CodeCommit	파이프라인은 CLI 또는 AWS CloudFormation을 사용하여 생성되며 `PollForSourceChanges` 파라미터는 JSON 출력에 표시되지 않지만 `true`로 설정됩니다.²	`BranchName": "main", "RepositoryName": "my-repo"`
Amazon S3	파이프라인은 콘솔로 생성되며 변경 감지 리소스는 콘솔에 의해 생성됩니다. 이 파라미터는 파이프라인 구조 출력에 표시되고 기본값은 `false`입니다.	`"S3Bucket": "my-bucket", "S3ObjectKey": "object.zip", "PollForSourceChanges": "false"`
Amazon S3	파이프라인은 CLI 또는 AWS CloudFormation을 사용하여 생성되며 `PollForSourceChanges` 파라미터는 JSON 출력에 표시되지 않지만 `true`로 설정됩니다.²	`"S3Bucket": "my-bucket", "S3ObjectKey": "object.zip"`
GitHub	파이프라인은 콘솔로 생성되며 변경 감지 리소스는 콘솔에 의해 생성됩니다. 이 파라미터는 파이프라인 구조 출력에 표시되고 기본값은 `false`입니다.	`"Owner": "MyGitHubAccountName", "Repo": "MyGitHubRepositoryName" "PollForSourceChanges": "false", "Branch": "main" "OAuthToken": "****"`
GitHub	파이프라인은 CLI 또는 AWS CloudFormation을 사용하여 생성되며 `PollForSourceChanges` 파라미터는 JSON 출력에 표시되지 않지만 `true`로 설정됩니다.²	`"Owner": "MyGitHubAccountName", "Repo": "MyGitHubRepositoryName", "Branch": "main", "OAuthToken": "****"`
	² `PollForSourceChanges`가 JSON 구조 또는 AWS CloudFormation 템플릿의 어느 지점에 추가된 경우 다음과 같이 표시됩니다. `"PollForSourceChanges": "true",` ³ 각 소스 공급자에 적용되는 변경 감지 리소스에 대한 자세한 내용은 변경 감지 방법을 참조하십시오.

공급자 유형별 구성 세부 정보

이 섹션에는 각 작업 공급자에 대한 유효한 configuration 파라미터가 나열되어 있습니다.

다음 예는 별도의 구성 파일 없이 콘솔에 생성된 파이프라인에 대해 Service Catalog를 사용하는 배포 작업의 유효한 구성을 보여줍니다.


"configuration": {
  "TemplateFilePath": "S3_template.json",
  "ProductVersionName": "devops S3 v2",
  "ProductType": "CLOUD_FORMATION_TEMPLATE",
  "ProductVersionDescription": "Product version description",
  "ProductId": "prod-example123456"
}

다음 예는 별도의 sample_config.json 구성 파일로 콘솔에 생성된 파이프라인에 대해 Service Catalog를 사용하는 배포 작업의 유효한 구성을 보여줍니다.


"configuration": {
  "ConfigurationFilePath": "sample_config.json",
  "ProductId": "prod-example123456"
}

다음 예는 Alexa Skills Kit를 사용하는 배포 작업에 유효한 구성을 보여줍니다.


"configuration": {
  "ClientId": "amzn1.application-oa2-client.aadEXAMPLE",
  "ClientSecret": "****",
  "RefreshToken": "****",
  "SkillId": "amzn1.ask.skill.22649d8f-0451-4b4b-9ed9-bfb6cEXAMPLE"
}

다음 예제는 수동 승인에 유효한 구성을 보여줍니다.


"configuration": {
  "CustomData": "Comments on the manual approval",
  "ExternalEntityLink": "http://my-url.com",
  "NotificationArn": "arn:aws:sns:us-west-2:12345EXAMPLE:Notification"
}

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

명령줄 참조

작업 구조 참조