Amazon CodeCatalyst는 더 이상 신규 고객에게 공개되지 않습니다. 기존 고객은 정상적으로 서비스를 계속 이용할 수 있습니다. 자세한 내용은 [CodeCatalyst에서 마이그레이션하는 방법](migration.md) 단원을 참조하십시오.
기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 워크플로 작업 구성
*작업*은 워크플로의 기본 구성 요소이며 워크플로 실행 중에 수행할 논리적 작업 단위 또는 태스크를 정의합니다. 일반적으로 워크플로에는 구성 방식에 따라 순차적으로 또는 병렬로 실행되는 여러 작업이 포함됩니다.
**Topics**
+ [작업 유형](#workflows-actions-types)
+ [워크플로에 작업 추가](workflows-add-action.md)
+ [워크플로에서 작업 제거](workflows-delete-action.md)
+ [사용자 지정 작업 개발](workflows-custom-action.md)
+ [작업을 작업 그룹으로 그룹화](workflows-group-actions.md)
+ [작업 순서 지정](workflows-depends-on.md)
+ [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md)
+ [사용할 작업 버전 지정](workflows-action-versions.md)
+ [사용 가능한 작업 버전 나열](workflows-action-versions-determine.md)
+ [작업의 소스 코드 보기](workflows-view-source.md)
+ [GitHub Actions와 통합](integrations-github-actions.md)
## 작업 유형
Amazon CodeCatalyst 워크플로 내에서 다음 유형의 작업을 사용할 수 있습니다.
**Topics**
+ [CodeCatalyst 작업](#workflows-actions-types-cc)
+ [CodeCatalyst Labs 작업](#workflows-actions-types-cc-labs)
+ [GitHub Actions](#workflows-actions-types-github)
+ [타사 작업](#workflows-actions-types-3p)
### CodeCatalyst 작업
*CodeCatalyst 작업*은 CodeCatalyst 개발 팀이 작성, 유지 및 완벽하게 지원하는 작업입니다.
애플리케이션 구축, 테스트 및 배포는 물론 AWS Lambda 함수 호출과 같은 기타 작업을 수행하기 위한 CodeCatalyst 작업이 있습니다.
다음 CodeCatalyst 작업을 사용할 수 있습니다.
+ **빌드**
이 작업은 아티팩트를 빌드하고 Docker 컨테이너에서 단위 테스트를 실행합니다. 자세한 내용은 [빌드 작업 추가](build-add-action.md) 섹션을 참조하세요.
+ **테스트**
이 작업은 애플리케이션 또는 아티팩트에 대해 통합 및 시스템 테스트를 실행합니다. 자세한 내용은 [테스트 작업 추가](test-add-action.md) 섹션을 참조하세요.
+ **Amazon S3 게시**
이 작업은 애플리케이션 아티팩트를 Amazon S3 버킷에 복사합니다. 자세한 내용은 [워크플로를 사용하여 Amazon S3에 파일 게시](s3-pub-action.md) 단원을 참조하십시오.
+ **AWS CDK 부트스트랩**
이 작업은가 CDK 앱을 배포하는 데 AWS CDK 필요한 리소스를 프로비저닝합니다. 자세한 내용은 [워크플로를 사용하여 AWS CDK 앱 부트스트래핑](cdk-boot-action.md) 단원을 참조하십시오.
+ **AWS CDK 배포**
이 작업은 AWS Cloud Development Kit (AWS CDK) 앱을 합성하고 배포합니다. 자세한 내용은 [워크플로를 사용하여 AWS CDK 앱 배포](cdk-dep-action.md) 단원을 참조하십시오.
+ **AWS Lambda 간접 호출**
이 작업은 AWS Lambda 함수를 호출합니다. 자세한 내용은 [워크플로를 사용하여 Lambda 함수 호출](lam-invoke-action.md) 단원을 참조하십시오.
+ **GitHub Actions**
이 작업은 *CodeCatalyst* 워크플로 내에서 GitHub Actions를 실행할 수 있는 CodeCatalyst 작업입니다. 자세한 내용은 [워크플로를 사용하여 Lambda 함수 호출](lam-invoke-action.md) 단원을 참조하십시오.
+ ** CloudFormation 스택 배포**
이 작업은 CloudFormation 스택을 배포합니다. 자세한 내용은 [CloudFormation 스택 배포](deploy-action-cfn.md) 단원을 참조하십시오.
+ **Amazon EKS에 배포**
이 작업은 Amazon ECS 작업 정의를 등록하고 Amazon ECS 서비스에 배포합니다. 자세한 내용은 [워크플로를 사용하여 Amazon ECS에 배포](deploy-action-ecs.md) 섹션을 참조하세요.
+ **Kubernetes 클러스터에 배포**
이 작업은 애플리케이션을 Kubernetes 클러스터에 배포합니다. 자세한 내용은 [워크플로를 사용하여 Amazon EKS에 배포](deploy-action-eks.md) 섹션을 참조하세요.
+ **Amazon ECS 태스크 정의 렌더링**
이 작업은 컨테이너 이미지 URI를 Amazon ECS 작업 정의 JSON 파일에 삽입하여 새 태스크 정의 파일을 생성합니다. 자세한 내용은 [Amazon ECS 작업 정의 수정](render-ecs-action.md) 섹션을 참조하세요.
CodeCatalyst 작업에 대한 설명서는 이 안내서와 각 작업의 읽어보기에서 확인할 수 있습니다.
사용 가능한 CodeCatalyst 작업과 워크플로에 추가하는 방법에 대한 자세한 내용은 [워크플로에 작업 추가](workflows-add-action.md) 섹션을 참조하세요.
### CodeCatalyst Labs 작업
*CodeCatalyst Labs 작업*은 실험 애플리케이션의 입증 근거인 Amazon CodeCatalyst Labs의 일부인 작업입니다. CodeCatalyst Labs 작업은 AWS 서비스와의 통합을 보여주기 위해 개발되었습니다.
다음 CodeCatalyst Labs 작업을 사용할 수 있습니다.
+ ** AWS Amplify 호스팅에 배포**
이 작업은 Amplify Hosting에 애플리케이션을 배포합니다.
+ **에 배포 AWS App Runner**
이 작업은 소스 이미지 리포지토리의 최신 이미지를 App Runner에 배포합니다.
+ **Amazon CloudFront 및 Amazon S3에 배포**
이 작업은 애플리케이션을 CloudFront 및 Amazon S3에 배포합니다.
+ **를 사용하여 배포 AWS SAM**
이 작업은 AWS Serverless Application Model (AWS SAM)를 사용하여 서버리스 애플리케이션을 배포합니다.
+ **Amazon CloudFront 캐시 무효화**
이 작업은 지정된 경로 집합에 대한 CloudFront 캐시를 무효화합니다.
+ **발신 웹후크**
이 작업을 통해 사용자는 HTTPS 요청을 사용하여 워크플로 내의 메시지를 임의의 웹 서버로 보낼 수 있습니다.
+ **에 게시 AWS CodeArtifact**
이 작업은 패키지를 CodeArtifact 리포지토리에 게시합니다.
+ **Amazon SNS에 게시**
이 작업을 통해 사용자는 주제를 생성하거나, 주제에 게시하거나, 주제를 구독하여 Amazon SNS와 통합할 수 있습니다.
+ **Amazon ECR에 게시**
이 작업은 Docker 이미지를 빌드하고 Amazon Elastic Container Registry(Amazon ECR) 리포지토리에 게시합니다.
+ **Amazon CodeGuru Security로 스캔**
이 작업은 구성된 코드 경로의 zip 아카이브를 생성하고 CodeGuru Security를 사용하여 코드 스캔을 실행합니다.
+ **Terraform Community Edition**
이 작업은 Terraform Community Edition `plan` 및 `apply` 작업을 실행합니다.
CodeCatalyst Labs 작업에 대한 설명서는 각 작업의 읽어보기에서 사용할 수 있습니다.
워크플로에 CodeCatalyst Labs 작업을 추가하고 해당 읽어보기를 보는 방법에 대한 자세한 내용은 [워크플로에 작업 추가](workflows-add-action.md) 섹션을 참조하세요.
### GitHub Actions
*GitHub 작업*은 GitHub 워크플로와 함께 사용하도록 개발되었다는 점을 제외하면 [CodeCatalyst 작업](#workflows-actions-types-cc)과 매우 유사합니다. GitHub Actions에 대한 자세한 내용은 [GitHub Actions](https://docs.github.com/en/actions) 설명서를 참조하세요.
CodeCatalyst 워크플로에서 기본 CodeCatalyst 작업과 함께 GitHub Actions를 사용할 수 있습니다.
편의를 위해 CodeCatalyst 콘솔은 인기 있는 여러 GitHub Actions에 대한 액세스를 제공합니다. [GitHub Marketplace](https://github.com/marketplace/actions)에 나열된 모든 GitHub 작업을 사용할 수도 있습니다(몇 가지 제한 사항이 적용됨).
GitHub Actions에 대한 설명서는 각 작업의 readme에서 사용할 수 있습니다.
자세한 내용은 [GitHub Actions와 통합](integrations-github-actions.md) 섹션을 참조하세요.
### 타사 작업
*타사 작업*은 타사 공급업체에서 작성하고 CodeCatalyst 콘솔에서 사용할 수 있는 작업입니다. 타사 작업의 예로는 각각 Mend 및 Sonar에서 작성한 **Mend SCA** 및 **SonarCloud Scan** 작업이 있습니다.
타사 작업에 대한 설명서는 각 작업의 readme에서 확인할 수 있습니다. 타사 공급업체에서 추가 문서를 제공할 수도 있습니다.
워크플로에 타사 작업을 추가하고 해당 읽어보기를 보는 방법에 대한 자세한 내용은 [워크플로에 작업 추가](workflows-add-action.md) 섹션을 참조하세요.
# 워크플로에 작업 추가
다음 지침에 따라 워크플로에 작업을 추가한 다음 구성합니다.
**작업 추가 및 구성**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. 왼쪽 상단에 **\$1 작업**을 선택하면 **작업** 카탈로그가 나타납니다.
1. 드롭다운 목록에서 다음 중 하나를 선택합니다.
+ **Amazon CodeCatalyst**를 선택하여 [CodeCatalyst](workflows-actions.md#workflows-actions-types-cc), [CodeCatalyst Labs ](workflows-actions.md#workflows-actions-types-cc-labs)또는 [타사](workflows-actions.md#workflows-actions-types-3p) 작업을 봅니다.
+ CodeCatalyst 작업에는 ** AWS레이블**이 있습니다.
+ CodeCatalyst Labs 작업에는 **by CodeCatalyst Labs** 레이블이 있습니다.
+ 타사 작업에는 **by *vendor*** 레이블이 있으며, 여기서 *vendor*는 타사 공급업체의 이름입니다.
+ **GitHub**를 선택하여 [큐레이션된 GitHub Actions 목록](integrations-github-action-add-curated.md)을 봅니다.
1. 작업 카탈로그에서 작업을 검색하고 다음 중 하나를 수행합니다.
+ 더하기 기호(**\$1**)를 선택하여 워크플로에 작업을 추가합니다.
+ 작업의 이름을 선택하여 읽어보기를 봅니다.
1. 작업을 구성합니다. 시각적 편집기를 사용하려면 **비주얼**을 선택하고, YAML 편집기를 사용하려면 **YAML**을 선택합니다. 자세한 지침은 다음 링크를 참조하세요.
[CodeCatalyst 작업](workflows-actions.md#workflows-actions-types-cc) 추가에 대한 지침은 다음을 참조하세요.
+ [빌드 작업 추가](build-add-action.md)
+ [테스트 작업 추가](test-add-action.md)
+ ['Amazon ECS에 배포' 작업 추가](deploy-action-ecs-adding.md)
+ ['Kubernetes 클러스터에 배포' 작업 추가](deploy-action-eks-adding.md)
+ ['스 CloudFormation 택 배포' 작업 추가](deploy-action-cfn-adding.md)
+ ['AWS CDK 배포' 작업 추가](cdk-dep-action-add.md)
+ ['AWS CDK bootstrap' 작업 추가](cdk-boot-action-add.md)
+ ['Amazon S3 게시' 작업 추가](s3-pub-action-add.md)
+ ['AWS Lambda 호출' 작업 추가](lam-invoke-action-add.md)
+ ['Amazon ECS 작업 정의 렌더링' 작업 추가](render-ecs-action-add.md)
[CodeCatalyst Labs 작업](workflows-actions.md#workflows-actions-types-cc-labs) 추가에 대한 지침은 다음을 참조하세요.
+ 작업의 readme입니다. 작업 카탈로그에서 작업의 이름을 선택하면 조사 결과를 확인할 수 있습니다.
[GitHub Actions](workflows-actions.md#workflows-actions-types-github) 추가에 대한 지침은 다음을 참조하세요.
+ [GitHub Actions와 통합](integrations-github-actions.md)
[타사 작업](workflows-actions.md#workflows-actions-types-3p) 추가에 대한 지침은 다음을 참조하세요.
+ 작업의 readme입니다. 작업 카탈로그에서 작업의 이름을 선택하면 조사 결과를 확인할 수 있습니다.
1. (선택 사항) YAML 코드가 유효한지 확인하려면 **검증**을 선택합니다.
1. **커밋**을 선택하여 변경 사항을 커밋합니다.
# 워크플로에서 작업 제거
다음 지침에 따라 워크플로에서 작업을 제거합니다.
------
#### [ Visual ]
**시각적 편집기를 사용하여 작업 제거**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 워크플로 다이어그램에서 제거하려는 작업에서 세로 줄임표 아이콘(![\[Ellipsis.\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/images/flows/elipsis.png))을 선택하고 **제거**를 선택합니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**YAML 편집기를 사용하여 작업 제거**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 제거하려는 작업이 포함된 YAML 섹션을 조사합니다.
섹션을 선택하고 키보드에서 delete 키를 누릅니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 사용자 지정 작업 개발
CodeCatalyst 작업 개발 키트(ADK)를 사용하여 워크플로에서 사용할 사용자 지정 작업을 개발할 수 있습니다. 그런 다음 해당 작업을 CodeCatalyst 작업 카탈로그에 게시하여 다른 CodeCatalyst 사용자가 워크플로에서 보고 사용할 수 있도록 할 수 있습니다.
**작업 개발, 테스트 및 게시(고급 태스크)**
1. 작업 개발에 필요한 도구와 패키지를 설치합니다.
1. 작업 코드를 저장할 CodeCatalyst 리포지토리를 만듭니다.
1. 작업을 초기화합니다. 이렇게 하면 자체 코드로 업데이트할 수 있는 작업 정의 파일(`action.yml`)을 포함하여 작업에 필요한 소스 파일이 정리됩니다.
1. 작업 코드를 부트스트랩하여 작업 프로젝트를 빌드, 테스트 및 릴리스하는 데 필요한 도구와 라이브러리를 가져옵니다.
1. 로컬 컴퓨터에서 작업을 빌드하고 변경 사항을 CodeCatalyst 리포지토리로 푸시합니다.
1. 로컬에서 단위 테스트를 통해 작업을 테스트하고, ADK에서 생성된 워크플로를 CodeCatalyst에서 실행합니다.
1. CodeCatalyst 콘솔에서 게시 버튼을 선택하여 CodeCatalyst 작업 카탈로그에 작업을 **게시**합니다.
자세한 단계는 [Amazon CodeCatalyst 작업 개발 키트 개발자 안내서](https://docs.aws.amazon.com/codecatalyst/latest/adk/what-is-action-development-kit.html)를 참조하세요.
# 작업을 작업 그룹으로 그룹화
*작업 그룹*에는 하나 이상의 작업이 포함됩니다. 작업을 작업 그룹으로 그룹화하면 워크플로를 체계적으로 관리할 수 있고, 서로 다른 그룹 간의 종속성을 구성할 수도 있습니다.
**참고**
다른 작업 그룹이나 작업 내에 작업 그룹을 중첩할 수 없습니다.
**Topics**
+ [작업 그룹 정의](#workflows-define-action-group)
+ [예시: 두 작업 그룹 정의](workflows-group-actions-example.md)
## 작업 그룹 정의
다음 지침에 따라 CodeCatalyst 작업 그룹을 정의합니다.
------
#### [ Visual ]
*사용할 수 없습니다. YAML을 선택하여 YAML 지침을 봅니다.*
------
#### [ YAML ]
**그룹 정의**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. `Actions`에서 다음과 유사한 코드를 추가합니다.
```
Actions:
action-group-name:
Actions:
action-1:
Identifier: aws/build@v1
Configuration:
...
action-2:
Identifier: aws/build@v1
Configuration:
...
```
다른 예시는 [예시: 두 작업 그룹 정의](workflows-group-actions-example.md)를 참조하세요. 자세한 내용은 [워크플로 YAML 정의](workflow-reference.md)의 [작업](workflow-reference.md#actions-reference)에서 `action-group-name` 속성에 관한 설명을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 예시: 두 작업 그룹 정의
다음 예시에서는 두 개의 Amazon CodeCatalyst 작업 그룹인 `BuildAndTest` 및 `Deploy`를 정의하는 방법을 보여줍니다. `BuildAndTest` 그룹에는 두 개의 작업(`Build` 및 `Test`)이 포함되며 `Deploy` 그룹에는 두 개의 작업(`DeployCloudFormationStack` 및 `DeployToECS`)도 포함됩니다.
```
Actions:
BuildAndTest: # Action group 1
Actions:
Build:
Identifier: aws/build@v1
Configuration:
...
Test:
Identifier: aws/managed-test@v1
Configuration:
Deploy: #Action group 2
Actions:
DeployCloudFormationStack:
Identifier: aws/cfn-deploy@v1
Configuration:
...
DeployToECS:
Identifier: aws/ecs-deploy@v1
Configuration:
...
```
# 작업 순서 지정
기본적으로 워크플로에 작업을 추가하면 [시각적 편집기](workflow.md#workflow.editors)에서 나란히 추가됩니다. 즉, 워크플로 실행을 시작할 때 작업이 병렬로 실행됩니다. 작업이 순차적으로 실행되고 시각적 편집기에서 세로로 표시되도록 하려면 작업 간에 종속성을 설정해야 합니다. 예를 들어, 테스트 작업이 빌드 작업 이후에 실행되도록 `Test`A 작업이 `Build` 작업에 종속되도록 설정할 수 있습니다.
작업과 작업 그룹 간에 종속성을 설정할 수 있습니다. 하나의 작업이 시작하기 위해 다른 여러 작업에 종속되도록 일대다 종속성을 구성할 수도 있습니다. [작업 간 종속성 설정](workflows-depends-on-set-up.md)의 가이드라인을 참조하여 종속성 설정이 워크플로의 YAML 구문을 준수하는지 확인하세요.
**Topics**
+ [작업 간의 종속성을 구성하는 방법의 예시](workflows-depends-on-examples.md)
+ [작업 간 종속성 설정](workflows-depends-on-set-up.md)
# 작업 간의 종속성을 구성하는 방법의 예시
다음 예시에서는 워크플로 정의 파일의 작업과 그룹 간에 종속성을 구성하는 방법을 보여줍니다.
**Topics**
+ [예시: 단순 종속성 구성](#workflows-depends-on-example-simple)
+ [예시: 작업에 종속되도록 작업 그룹 구성](#workflows-depends-on-example-action-groups-actions)
+ [예시: 다른 작업 그룹에 종속되도록 작업 그룹 구성](#workflows-depends-on-example-two-action-groups)
+ [예시: 여러 작업에 종속되도록 작업 그룹 구성](#workflows-depends-on-example-advanced)
## 예시: 단순 종속성 구성
다음 예시에서는 `DependsOn` 속성을 사용하여 `Build` 작업에 따라 `Test` 작업을 구성하는 방법을 보여줍니다.
```
Actions:
Build:
Identifier: aws/build@v1
Configuration:
...
Test:
DependsOn:
- Build
Identifier: aws/managed-test@v1
Configuration:
...
```
## 예시: 작업에 종속되도록 작업 그룹 구성
다음 예시에서는 `FirstAction` 작업에 따라 `DeployGroup` 작업 그룹을 구성하는 방법을 보여줍니다. 작업과 작업 그룹은 동일한 수준에 있습니다.
```
Actions:
FirstAction: #An action outside an action group
Identifier: aws/github-actions-runner@v1
Configuration:
...
DeployGroup: #An action group containing two actions
DependsOn:
- FirstAction
Actions:
DeployAction1:
...
DeployAction2:
...
```
## 예시: 다른 작업 그룹에 종속되도록 작업 그룹 구성
다음 예시에서는 `BuildAndTestGroup` 작업 그룹에 따라 `DeployGroup` 작업 그룹을 구성하는 방법을 보여줍니다. 작업 그룹은 동일한 수준에 있습니다.
```
Actions:
BuildAndTestGroup: # Action group 1
Actions:
BuildAction:
...
TestAction:
...
DeployGroup: #Action group 2
DependsOn:
- BuildAndTestGroup
Actions:
DeployAction1:
...
DeployAction2:
...
```
## 예시: 여러 작업에 종속되도록 작업 그룹 구성
다음 예시에서는 `FirstAction` 작업, `SecondAction` 작업 및 `BuildAndTestGroup` 작업 그룹에 따라 `DeployGroup` 작업 그룹을 구성하는 방법을 보여줍니다. `DeployGroup`은 `FirstAction`, `SecondAction` 및 `BuildAndTestGroup`과 동일한 수준에 있습니다.
```
Actions:
FirstAction: #An action outside an action group
...
SecondAction: #Another action
...
BuildAndTestGroup: #Action group 1
Actions:
Build:
...
Test:
...
DeployGroup: #Action group 2
DependsOn:
- FirstAction
- SecondAction
- BuildAndTestGroup
Actions:
DeployAction1:
...
DeployAction2:
...
```
# 작업 간 종속성 설정
다음 지침에 따라 워크플로의 작업 간 종속성을 설정합니다.
종속성을 구성할 때는 다음 지침을 따르세요.
+ 작업이 그룹 내에 있는 경우 해당 작업은 동일한 그룹 내의 다른 작업에만 의존할 수 있습니다.
+ 작업 및 작업 그룹은 YAML 계층 구조에서 *동일한 수준*의 다른 작업 및 작업 그룹에 의존할 수 있지만 다른 수준에서는 의존할 수 *없습니다*.
------
#### [ Visual ]
**시각적 편집기를 사용하여 종속성 설정**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 워크플로 다이어그램에서 다른 작업에 종속될 작업을 선택합니다.
1. **입력** 탭을 선택합니다.
1. **종속 대상 - 선택 사항**에서 다음을 수행합니다.
이 작업을 실행하기 위해 성공적으로 실행해야 하는 작업, 작업 그룹 또는 게이트를 지정합니다.
'depends on' 함수에 대한 자세한 내용은 [작업 순서 지정](workflows-depends-on.md) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**YAML 편집기를 사용하여 종속성 설정**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 다른 항목에 종속되는 작업에서 다음과 유사한 코드를 추가합니다
```
action-name:
DependsOn:
- action-1
```
더 많은 예시는 [작업 간의 종속성을 구성하는 방법의 예시](workflows-depends-on-examples.md)를 참조합니다. 일반 지침은 [작업 간 종속성 설정](#workflows-depends-on-set-up) 섹션을 참조하세요. 자세한 내용은 작업에 대한 [워크플로 YAML 정의](workflow-reference.md)의 `DependsOn` 속성 설명을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 작업 간 아티팩트 및 파일 공유
*아티팩트*는 워크플로 작업의 출력이며 일반적으로 폴더 또는 파일 아카이브로 구성됩니다. 아티팩트를 사용하면 작업 간에 파일과 정보를 공유할 수 있기 때문에 아티팩트가 중요합니다.
예를 들어, `sam-template.yml` 파일을 *생성* 하는 빌드 작업이 있을 수 있지만 배포 작업에서 파일을 *사용*하려는 경우가 있습니다. 이 시나리오에서는 아티팩트를 사용하여 빌드 작업이 배포 작업과 `sam-template.yml` 파일을 공유하도록 허용합니다. 코드는 다음과 같을 것입니다.
```
Actions:
BuildAction:
Identifier: aws/build@v1
Steps:
- Run: sam package --output-template-file sam-template.yml
Outputs:
Artifacts:
- Name: MYARTIFACT
Files:
- sam-template.yml
DeployAction:
Identifier: aws/cfn-deploy@v1
Inputs:
Artifacts:
- MYARTIFACT
Configuration:
template: sam-template.yml
```
이전 코드에서 빌드 작업(`BuildAction`)은 `sam-template.yml` 파일을 생성한 다음 라는 출력 아티팩트 `MYARTIFACT`에 추가합니다. 후속 배포 작업(`DeployAction`)은 `MYARTIFACT`를 입력으로 지정하여 `sam-template.yml` 파일에 대한 액세스 권한을 부여합니다.
**Topics**
+ [아티팩트를 출력 및 입력으로 지정하지 않고 공유할 수 있나요?](#workflows-working-artifacts-share)
+ [워크플로 간에 아티팩트를 공유할 수 있나요?](#workflows-working-artifacts-share-wf)
+ [아티팩트 예시](workflows-working-artifacts-ex.md)
+ [출력 아티팩트 정의](workflows-working-artifacts-output.md)
+ [입력 아티팩트 정의](workflows-working-artifacts-refer.md)
+ [아티팩트의 파일 참조](workflows-working-artifacts-refer-files.md)
+ [아티팩트 다운로드](workflows-download-workflow-outputs.md)
## 아티팩트를 출력 및 입력으로 지정하지 않고 공유할 수 있나요?
예, 작업의 YAML 코드의 `Outputs` 및 `Inputs` 섹션에서 아티팩트를 지정하지 않고 작업 간에 아티팩트를 공유할 수 있습니다. 이렇게 하려면 컴퓨팅 공유를 켜야 합니다. 컴퓨팅 공유 및 아티팩트가 켜져 있을 때 아티팩트를 지정하는 방법에 대한 자세한 내용은 [작업 간에 컴퓨팅 공유](compute-sharing.md) 섹션을 참조하세요.
**참고**
컴퓨팅 공유 기능을 사용하면 `Outputs` 및 `Inputs` 섹션이 필요 없어 워크플로의 YAML 코드를 간소화할 수 있지만, 이 기능을 켜기 전에 알아두어야 할 제한 사항이 있습니다. 이러한 제한에 대한 자세한 내용은 [컴퓨팅 공유 고려 사항](compute-sharing.md#compare-compute-sharing) 섹션을 참조하세요.
## 워크플로 간에 아티팩트를 공유할 수 있나요?
아니요. 서로 다른 워크플로 간에 아티팩트를 공유할 수 없지만 동일한 워크플로 내의 작업 간에 아티팩트를 공유할 수 있습니다.
# 아티팩트 예시
다음 예시에서는 Amazon CodeCatalyst 워크플로 정의 파일에서 아티팩트를 출력, 입력 및 참조하는 방법을 보여줍니다.
**Topics**
+ [예시: 아티팩트 출력](#workflows-working-artifacts-ex-basic)
+ [예시: 다른 작업에서 생성된 아티팩트 입력](#workflows-working-artifacts-ex-ref)
+ [예시: 여러 아티팩트에서 파일 참조](#workflows-working-artifacts-ex-ref-file)
+ [예시: 단일 아티팩트에서 파일 참조](#workflows-working-artifacts-ex-ref-file-one)
+ [예시: WorkflowSource가 있을 때 아티팩트의 파일 참조](#workflows-working-artifacts-ex-ref-file-wf-source)
+ [예시: 작업 그룹이 있을 때 아티팩트의 파일 참조](#workflows-working-artifacts-ex-groups)
## 예시: 아티팩트 출력
다음 예시에서는 두 개의 .jar 파일이 포함된 아티팩트를 출력하는 방법을 보여줍니다.
```
Actions:
Build:
Identifier: aws/build@v1
Outputs:
Artifacts:
- Name: ARTIFACT1
Files:
- build-output/file1.jar
- build-output/file2.jar
```
## 예시: 다른 작업에서 생성된 아티팩트 입력
다음 예시에서는 `BuildActionA`의 `ARTIFACT4` 아티팩트를 출력하고 `BuildActionB`에 입력하는 방법을 보여줍니다.
```
Actions:
BuildActionA:
Identifier: aws/build@v1
Outputs:
Artifacts:
- Name: ARTIFACT4
Files:
- build-output/file1.jar
- build-output/file2.jar
BuildActionB:
Identifier: aws/build@v1
Inputs:
Artifacts:
- ARTIFACT4
Configuration:
```
## 예시: 여러 아티팩트에서 파일 참조
다음 예시에서는 `BuildActionC`의 `ART5` 및 `ART6`라는 두 개의 아티팩트를 출력한 다음 `BuildActionD`(`Steps` 아래)의 `file5.txt`(`ART5` 아티팩트) 및 `file6.txt`(`ART6` 아티팩트)라는 두 개의 파일을 참조하는 방법을 보여줍니다.
**참고**
파일 참조에 대한 자세한 내용은 [아티팩트의 파일 참조](workflows-working-artifacts-refer-files.md) 섹션을 참조하세요.
**참고**
예시는 사용 중인 `$CATALYST_SOURCE_DIR_ART5` 접두사를 보여주지만 이를 생략할 수 있습니다. 이는 `ART5`가 *기본 입력*이기 때문입니다. 기본 입력에 대한 자세한 내용은 [아티팩트의 파일 참조](workflows-working-artifacts-refer-files.md) 섹션을 참조하세요.
```
Actions:
BuildActionC:
Identifier: aws/build@v1
Outputs:
Artifacts:
- Name: ART5
Files:
- build-output/file5.txt
- Name: ART6
Files:
- build-output/file6.txt
BuildActionD:
Identifier: aws/build@v1
Inputs:
Artifacts:
- ART5
- ART6
Configuration:
Steps:
- run: cd $CATALYST_SOURCE_DIR_ART5/build-output && cat file5.txt
- run: cd $CATALYST_SOURCE_DIR_ART6/build-output && cat file6.txt
```
## 예시: 단일 아티팩트에서 파일 참조
다음 예시에서는 `BuildActionE`의 `ART7` 아티팩트를 출력한 다음 `BuildActionF`(`Steps` 아래)의 `file7.txt`(`ART7` 아티팩트) 파일을 참조하는 방법을 보여줍니다.
[예시: 여러 아티팩트에서 파일 참조](#workflows-working-artifacts-ex-ref-file)에서와 같이 참조에 `build-output` 디렉터리 앞에 `$CATALYST_SOURCE_DIR_`*artifact-name* 접두사가 필요하지 않은 것을 확인할 수 있습니다. 이는 `Inputs`에 지정된 항목이 하나뿐이기 때문입니다.
**참고**
파일 참조에 대한 자세한 내용은 [아티팩트의 파일 참조](workflows-working-artifacts-refer-files.md) 섹션을 참조하세요.
```
Actions:
BuildActionE:
Identifier: aws/build@v1
Outputs:
Artifacts:
- Name: ART7
Files:
- build-output/file7.txt
BuildActionF:
Identifier: aws/build@v1
Inputs:
Artifacts:
- ART7
Configuration:
Steps:
- run: cd build-output && cat file7.txt
```
## 예시: WorkflowSource가 있을 때 아티팩트의 파일 참조
다음 예시에서는 `BuildActionG`의 `ART8` 아티팩트를 출력한 다음 `BuildActionH`(`Steps` 아래)의 `file8.txt`(`ART8` 아티팩트) 파일을 참조하는 방법을 보여줍니다.
참조에 `$CATALYST_SOURCE_DIR_`*artifact-name* 접두사가 [예시: 여러 아티팩트에서 파일 참조](#workflows-working-artifacts-ex-ref-file)에서와 같이 어떻게 필요한지 확인합니다. 이는 `Inputs`(소스 및 아티팩트)에 여러 항목이 지정되어 있기 때문에 파일을 찾을 위치를 나타내는 접두사가 필요합니다.
**참고**
파일 참조에 대한 자세한 내용은 [아티팩트의 파일 참조](workflows-working-artifacts-refer-files.md) 섹션을 참조하세요.
```
Actions:
BuildActionG:
Identifier: aws/build@v1
Outputs:
Artifacts:
- Name: ART8
Files:
- build-output/file8.txt
BuildActionH:
Identifier: aws/build@v1
Inputs:
Sources:
- WorkflowSource
Artifacts:
- ART8
Configuration:
Steps:
- run: cd $CATALYST_SOURCE_DIR_ART8/build-output && cat file8.txt
```
## 예시: 작업 그룹이 있을 때 아티팩트의 파일 참조
다음 예시에서는 `ActionGroup1`, `ActionI`의 `ART9` 아티팩트를 출력한 다음 `ActionJ`의 `file9.txt`(`ART9` 아티팩트) 파일을 참조하는 방법을 보여줍니다.
파일 참조에 대한 자세한 내용은 [아티팩트의 파일 참조](workflows-working-artifacts-refer-files.md) 섹션을 참조하세요.
```
Actions:
ActionGroup1:
Actions:
ActionI:
Identifier: aws/build@v1
Outputs:
Artifacts:
- Name: ART9
Files:
- build-output/file9.yml
ActionJ:
Identifier: aws/cfn-deploy@v1
Inputs:
Sources:
- WorkflowSource
Artifacts:
- ART9
Configuration:
template: /artifacts/ActionGroup1@ActionJ/ART9/build-output/file9.yml
```
# 출력 아티팩트 정의
다음 지침에 따라 Amazon CodeCatalyst 작업이 출력할 아티팩트를 정의합니다. 그러면 이 아티팩트를 다른 작업에서 사용할 수 있게 됩니다.
**참고**
모든 작업이 출력 아티팩트를 지원하는 것은 아닙니다. 작업이 이를 지원하는지 확인하려면 다음에 나오는 시각적 편집기 지침을 실행하고 **출력** 탭에서 작업에 **출력 아티팩트** 버튼이 포함되어 있는지 확인합니다. 포함되어 있다면 출력 아티팩트가 지원됩니다.
------
#### [ Visual ]
**시각적 편집기를 사용하여 출력 아티팩트 정의**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 워크플로 다이어그램에서 아티팩트를 생성할 작업을 선택합니다.
1. **출력** 탭을 선택합니다.
1. **아티팩트**에서 **아티팩트 추가**를 선택합니다.
1. **아티팩트 추가**를 선택하고 다음과 같이 필드에 정보를 입력합니다.
**빌드 아티팩트 이름**
작업에서 생성된 아티팩트의 이름을 지정합니다. 아티팩트 이름은 워크플로 내에서 고유해야 하며 영숫자 문자(a-z, A-Z, 0-9) 및 밑줄(\$1)로 제한됩니다. 공백, 하이픈(-) 및 특수 문자는 허용되지 않습니다. 출력 아티팩트 이름에서 공백, 하이픈 및 기타 특수 문자를 활성화하는 데 따옴표를 사용할 수 없습니다.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
**빌드로 생성한 파일**
CodeCatalyst가 작업으로 출력되는 아티팩트에 포함하는 파일을 지정합니다. 이러한 파일은 실행 시 워크플로 작업에 의해 생성되며 소스 리포지토리에서도 사용할 수 있습니다. 파일 경로는 소스 리포지토리 또는 이전 작업의 아티팩트에 상주할 수 있으며 소스 리포지토리 또는 아티팩트 루트와 관련이 있습니다. glob 패턴을 사용하여 경로를 지정할 수 있습니다. 예시:
+ 빌드 위치 또는 소스 리포지토리 위치의 루트에 있는 단일 파일을 지정하려면 `my-file.jar`를 사용합니다..
+ 하위 디렉터리에 단일 파일을 지정하려면 `directory/my-file.jar` 또는 `directory/subdirectory/my-file.jar`를 사용합니다.
+ 모든 파일을 지정하려면 `"**/*"`를 사용합니다. `**` glob 패턴은 임의의 수의 하위 디렉터리와 일치함을 나타냅니다.
+ `directory`라는 디렉터리에 있는 모든 파일 및 디렉터리를 지정하려면 `"directory/**/*"`를 사용합니다. `**` glob 패턴은 임의의 수의 하위 디렉터리와 일치함을 나타냅니다.
+ `directory`라는 디렉터리의 모든 파일을 지정하되 해당 하위 디렉터리는 지정하지 않으려면 `"directory/*"`를 사용합니다.
**참고**
파일 경로에 별표(`*`) 또는 기타 특수 문자가 하나 이상 포함된 경우 경로를 큰따옴표(`""`)로 묶습니다. 특수 문자에 대한 자세한 내용은 [구문 지침 및 규칙](workflow-reference.md#workflow.terms.syntax.conv) 섹션을 참조하세요.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
**참고**
파일 경로에 접두사를 추가하여 찾을 아티팩트 또는 소스를 나타내야 할 수 있습니다. 자세한 내용은 [소스 리포지토리 파일 참조](workflows-sources-reference-files.md) 및 [아티팩트의 파일 참조](workflows-working-artifacts-refer-files.md) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**YAML 편집기를 사용하여 출력 아티팩트 정의**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 워크플로 작업에서 다음과 유사한 코드를 추가합니다.
```
action-name:
Outputs:
Artifacts:
- Name: artifact-name
Files:
- file-path-1
- file-path-2
```
더 많은 예시는 [아티팩트 예시](workflows-working-artifacts-ex.md)를 참조합니다. 자세한 내용은 작업에 해당하는 [워크플로 YAML 정의](workflow-reference.md) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 입력 아티팩트 정의
다른 Amazon CodeCatalyst 작업에서 생성된 아티팩트를 사용하려면 현재 작업의 입력으로 지정해야 합니다. 여러 아티팩트를 입력으로 지정할 수 있습니다. 이는 작업에 따라 다릅니다. 자세한 내용은 작업에 해당하는 [워크플로 YAML 정의](workflow-reference.md) 섹션을 참조하세요.
**참고**
다른 워크플로의 아티팩트를 참조할 수 없습니다.
다음 지침에 따라 다른 작업의 아티팩트를 현재 작업에 대한 입력으로 지정합니다.
**사전 조건**
시작하기 전에 다른 작업에서 아티팩트가 출력되어 있는지 확인하세요. 자세한 내용은 [출력 아티팩트 정의](workflows-working-artifacts-output.md) 섹션을 참조하세요. 아티팩트를 출력하면 다른 작업에서 사용할 수 있습니다.
------
#### [ Visual ]
**아티팩트를 작업에 대한 입력으로 지정(시각적 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 워크플로 다이어그램에서 아티팩트를 입력으로 지정하려는 작업을 선택합니다.
1. **입력**을 선택합니다.
1. **아티팩트 - 선택 사항**에서 다음을 수행합니다.
이 작업에 대한 입력으로 제공하려는 이전 작업의 아티팩트를 지정합니다. 이러한 아티팩트는 이전 작업에서 출력 아티팩트로 이미 정의되어 있어야 합니다.
입력 아티팩트를 지정하지 않으면 `action-name/Inputs/Sources` 아래에 소스 리포지토리를 하나 이상 지정해야 합니다.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
**참고**
**아티팩트 - 선택적** 드롭다운 목록을 사용할 수 없거나(시각적 편집기) YAML(YAML 편집기)을 검증할 때 오류가 발생하는 경우 작업이 하나의 입력만 지원하기 때문일 수 있습니다. 이 경우 소스 입력을 제거해 보세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**아티팩트를 작업에 대한 입력으로 지정(YAML 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 아티팩트를 입력으로 지정하려는 작업에서 다음과 유사한 코드를 추가합니다.
```
action-name:
Inputs:
Artifacts:
- artifact-name
```
더 많은 예시는 [아티팩트 예시](workflows-working-artifacts-ex.md)를 참조합니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 아티팩트의 파일 참조
아티팩트 내에 파일이 있고 Amazon CodeCatalyst 워크플로 작업 중 하나에서 이 파일을 참조해야 하는 경우 다음 절차를 수행하세요.
**참고**
또한 [소스 리포지토리 파일 참조](workflows-sources-reference-files.md) 섹션도 참조하세요.
------
#### [ Visual ]
*사용할 수 없습니다. YAML을 선택하여 YAML 지침을 봅니다.*
------
#### [ YAML ]
**아티팩트의 파일 참조(YAML 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 파일을 참조하려는 작업에서 다음과 유사한 코드를 추가합니다.
```
Actions:
My-action:
Inputs:
Sources:
- WorkflowSource
Artifacts:
- artifact-name
Configuration:
template: artifact-path/path/to/file.yml
```
이전 코드에서 다음을 바꿉니다.
+ *artifact-name*: 아티팩트 이름으로 바꿉니다.
+ *artifact-path*: 다음 테이블의 값으로 바꿉니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/workflows-working-artifacts-refer-files.html)
예시는 [아티팩트 예시](workflows-working-artifacts-ex.md) 섹션을 참조하세요.
**참고**
다음과 같은 경우 *artifact-path*를 생략하고 아티팩트 루트 디렉터리를 기준으로 파일 경로를 지정할 수 있습니다.
참조를 포함하려는 작업이 `Inputs` 아래에 하나의 항목만 포함합니다(예: 입력 아티팩트 하나만 포함되고 소스는 포함되지 않음).
참조하려는 파일은 기본 입력에 있습니다. *기본 입력*은 `WorkflowSource`이거나 `WorkflowSource`가 없는 경우 나열된 첫 번째 입력 아티팩트입니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 아티팩트 다운로드
문제 해결을 위해 Amazon CodeCatalyst 워크플로 작업에서 생성된 아티팩트를 다운로드하여 검사할 수 있습니다. 다운로드할 수 있는 아티팩트에는 다음과 같이 두 가지 유형이 있습니다.
+ **소스 아티팩트** - 실행이 시작될 때 존재했던 소스 리포지토리 콘텐츠의 스냅샷이 포함된 아티팩트입니다.
+ **워크플로 아티팩트** - 워크플로 구성 파일의 `Outputs` 속성에 정의된 아티팩트입니다.
**워크플로에서 아티팩트 출력 다운로드**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. 워크플로 이름에서 **실행**을 선택합니다.
1. **실행 기록**의 **실행 ID** 열에서 실행을 선택합니다. 예를 들어 `Run-95a4d`입니다.
1. 실행 이름에서 **아티팩트**를 선택합니다.
1. 아티팩트 옆에 있는 **다운로드**를 선택합니다. 아카이브 파일이 다운로드됩니다. 파일 이름은 7개의 무작위 문자로 구성됩니다.
1. 원하는 아카이브 추출 유틸리티를 사용하여 아카이브를 추출합니다.
# 사용할 작업 버전 지정
기본적으로 워크플로우에 작업을 추가하면 Amazon CodeCatalyst는 해당 형식을 사용하여 워크플로우 정의 파일에 정식 버전을 추가합니다.
`vmajor.minor.patch`
예제:
```
My-Build-Action:
Identifier: aws/build@v1.0.0
```
워크플로에서 항상 최신 마이너 또는 패치 버전의 작업을 사용하도록 `Identifier` 속성에서 정식 버전을 단축할 수 있습니다.
예를 들어, 다음을 지정해야 합니다.
```
My-CloudFormation-Action:
Identifier: aws/cfn-deploy@v1.0
```
...그리고 최신 패치 버전은 이며`1.0.4`, 그러면 작업은 `1.0.4` 버전을 사용합니다. 이후 버전 `1.0.5`가 릴리스되면 작업은 `1.0.5` 버전을 사용합니다. 마이너 버전 `1.1.0`이 릴리스되면 작업은 `1.0.5` 버전을 사용합니다.
버전 지정에 대한 자세한 지침은 다음 주제 중 하나를 참조하세요.
다음 지침에 따라 워크플로에서 사용할 작업 버전을 지정합니다. 최신 메이저 또는 마이너 버전 또는 특정 패치 버전을 지정할 수 있습니다.
작업의 최신 마이너 또는 패치 버전을 사용하는 것이 좋습니다.
------
#### [ Visual ]
*사용할 수 없습니다. YAML을 선택하여 YAML 지침을 봅니다.*
------
#### [ YAML ]
**작업의 최신 버전 또는 특정 패치 버전을 사용하도록 워크플로 구성**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 버전을 편집하려는 작업을 찾습니다.
1. 작업의 `Identifier` 속성을 찾아 버전을 다음 중 하나로 설정합니다.
+ action-identifier@v*major* - 이 구문을 사용하면 워크플로가 특정 메이저 버전을 사용하도록 하고 최신 마이너 및 패치 버전을 자동으로 선택할 수 있습니다.
+ action-identifier@v*major*.*minor* - 이 구문을 사용하면 워크플로가 특정 마이너 버전을 사용하도록 하고 최신 패치 버전을 자동으로 선택할 수 있습니다.
+ action-identifier@v*major*.*minor*.*patch* – 워크플로가 특정 패치 버전을 사용하도록 하려면 이 구문을 사용합니다.
**참고**
사용 가능한 버전이 확실하지 않은 경우 [사용 가능한 작업 버전 나열](workflows-action-versions-determine.md) 섹션을 참조하세요.
**참고**
메이저 버전은 생략할 수 없습니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 사용 가능한 작업 버전 나열
다음 지침에 따라 워크플로에서 사용할 수 있는 작업의 버전을 확인하세요.
------
#### [ Visual ]
**사용 가능한 작업 버전 확인**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 확인하려는 버전의 작업을 찾습니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택하거나 새로 워크플로를 생성합니다. 워크플로 생성에 대한 자세한 내용은 [워크플로 생성](workflows-create-workflow.md) 섹션을 참조하세요.
1. **편집**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **Amazon CodeCatalyst**를 선택하여 CodeCatalyst, CodeCatalyst Labs 및 타사 작업을 보거나 **GitHub**를 선택하여 선별된 GitHub Actions를 볼 수 있습니다.
1. 작업을 검색하고 해당 이름을 선택합니다. **\$1**(더하기 부호)를 선택합니다.
작업에 대한 세부 정보가 표시됩니다.
1. 작업 세부 정보 대화 상자의 오른쪽 상단에서 **버전** 드롭다운 목록을 선택하여 사용 가능한 작업의 버전 목록을 확인합니다.
------
#### [ YAML ]
*사용할 수 없습니다. 시각적 편집기 지침을 보려면 '비주얼'을 선택합니다.*
------
# 작업의 소스 코드 보기
작업의 소스 코드를 보고 위험한 코드, 보안 취약성 또는 기타 결함이 없는지 확인할 수 있습니다.
다음 지침에 따라 [CodeCatalyst](workflows-actions.md#workflows-actions-types-cc), [CodeCatalyst Labs](workflows-actions.md#workflows-actions-types-cc-labs) 또는 [타사](workflows-actions.md#workflows-actions-types-3p) 작업의 소스 코드를 확인합니다.
**참고**
[GitHub 작업](workflows-actions.md#workflows-actions-types-github)의 소스 코드를 보려면 [GitHub Marketplace](https://github.com/marketplace/actions)의 작업 페이지로 이동합니다. 페이지에는 작업의 소스 코드를 찾을 수 있는 작업의 리포지토리에 대한 링크가 포함되어 있습니다.
**참고**
[빌드](build-workflow-actions.md), [테스트](test-workflow-actions.md), [GitHub Actions](integrations-github-action-add.md) 등의 CodeCatalyst 작업의 소스 코드는 볼 수 없습니다.
**참고**
AWS 는 GitHub Actions 또는 타사 작업의 작업 코드를 지원하거나 보장하지 않습니다.
**작업의 소스 코드 보기**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 코드를 보려는 작업을 찾습니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택하거나 새로 워크플로를 생성합니다. 워크플로 생성에 대한 자세한 내용은 [워크플로 생성](workflows-create-workflow.md) 섹션을 참조하세요.
1. **편집**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **Amazon CodeCatalyst**를 선택하여 CodeCatalyst, CodeCatalyst Labs 및 타사 작업을 확인합니다.
1. 작업을 검색하고 해당 이름을 선택합니다. **\$1**(더하기 부호)를 선택합니다.
작업에 대한 세부 정보가 표시됩니다.
1. 작업 세부 정보 대화 상자 하단에서 **다운로드**를 선택합니다.
작업의 소스 코드가 있는 Amazon S3 버킷을 보여주는 페이지가 나타납니다. 자세한 내용은 *Amazon Simple Storage Service 사용 안내서*의 [Amazon S3란 무엇인가요?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)를 참조하세요.
1. 코드를 검사하여 품질 및 보안에 대한 기대치를 충족하는지 확인합니다.
# GitHub Actions와 통합
*GitHub 작업*은 GitHub 워크플로와 함께 사용하도록 개발되었다는 점을 제외하면 [CodeCatalyst 작업](workflows-actions.md#workflows-actions-types-cc)과 매우 유사합니다. GitHub Actions에 대한 자세한 내용은 [GitHub Actions](https://docs.github.com/en/actions) 설명서를 참조하세요.
CodeCatalyst 워크플로에서 기본 CodeCatalyst 작업과 함께 GitHub Actions를 사용할 수 있습니다.
CodeCatalyst 워크플로에 GitHub 작업을 추가하는 방법은 두 가지가 있습니다.
+ CodeCatalyst 콘솔의 큐레이션된 목록에서 GitHub 작업을 선택할 수 있습니다. 몇 가지 인기 있는 GitHub Actions를 사용할 수 있습니다. 자세한 내용은 [큐레이션된 GitHub 작업 추가](integrations-github-action-add-curated.md) 섹션을 참조하세요.
+ CodeCatalyst 콘솔에서 사용하려는 GitHub Actions를 사용할 수 없는 경우 **GitHub Actions** 작업을 사용하여 추가할 수 있습니다.
***GitHub Actions*** 작업은 GitHub Actions를 래핑하고 CodeCatalyst 워크플로와 호환되는 *CodeCatalyst 작업*입니다.
다음은 [Super-Linter](https://github.com/marketplace/actions/super-linter) GitHub Actions를 래핑하는 **GitHub Actions**의 예입니다.
```
Actions:
GitHubAction:
Identifier: aws/github-actions-runner@v1
Configuration:
Steps:
- name: Lint Code Base
uses: github/super-linter@v4
env:
VALIDATE_ALL_CODEBASE: "true"
DEFAULT_BRANCH: main
```
이전 코드에서 CodeCatalyst **GitHub Actions** 작업(`aws/github-actions-runner@v1`로 식별됨)은 Super-Linter OSS 작업(`github/super-linter@v4`로 식별됨)을 래핑하여 CodeCatalyst 워크플로에서 작동하도록 합니다.
자세한 내용은 ['GitHub Actions' 작업 추가](integrations-github-action-add.md) 섹션을 참조하세요.
이전 예시와 같이 큐레이션된 작업과 큐레이션되지 않은 모든 GitHub Actions는 **GitHub Actions**(`aws/github-actions-runner@v1`)으로 래핑해야 합니다. 작업이 제대로 작동하려면 래퍼가 필요합니다.
**Topics**
+ [GitHub Actions는 CodeCatalyst 작업과 어떻게 다릅니까?](#integrations-github-actions-how-different)
+ [GitHub Actions는 워크플로의 다른 CodeCatalyst 작업과 상호 작용할 수 있습니까?](#integrations-github-actions-interactions.title)
+ [어떤 GitHub Actions를 사용할 수 있나요?](#integrations-github-actions-supported)
+ [CodeCatalyst의 GitHub Actions 제한 사항](#integrations-github-actions-limitations)
+ [GitHub 작업(상위 단계)을 추가하려면 어떻게 해야 하나요?](#integrations-github-actions-how-to)
+ [GitHub 작업은 GitHub에서 실행되나요?](#integrations-github-actions-where-it-runs)
+ [GitHub 워크플로도 사용할 수 있나요?](#integrations-github-actions-workflows-support.title)
+ ['GitHub Actions' 작업에 사용되는 런타임 이미지](#integrations-github-actions-runtime)
+ [자습서: GitHub 작업을 사용한 린트 코드](integrations-github-action-tutorial.md)
+ ['GitHub Actions' 작업 추가](integrations-github-action-add.md)
+ [큐레이션된 GitHub 작업 추가](integrations-github-action-add-curated.md)
+ [GitHub 출력 파라미터 내보내기](integrations-github-action-export.md)
+ [GitHub 출력 파라미터 참조](integrations-github-action-referencing.md)
+ ['GitHub Actions' 작업 YAML](github-action-ref.md)
## GitHub Actions는 CodeCatalyst 작업과 어떻게 다릅니까?
CodeCatalyst 워크플로 내에서 사용되는 GitHub Actions는 CodeCatalyst 작업 AWS 과 동일한 수준의 액세스 및 CodeCatalyst 기능(예: [환경](deploy-environments.md) 및 [문제](issues.md))과의 통합을 제공하지 않습니다. CodeCatalyst
## GitHub Actions는 워크플로의 다른 CodeCatalyst 작업과 상호 작용할 수 있습니까?
예. 예를 들어 GitHub Actions는 다른 CodeCatalyst 작업에서 생성된 변수를 입력으로 사용할 수 있으며, 출력 파라미터 및 아티팩트를 CodeCatalyst 작업과 공유할 수도 있습니다. 자세한 내용은 [GitHub 출력 파라미터 내보내기](integrations-github-action-export.md) 및 [GitHub 출력 파라미터 참조](integrations-github-action-referencing.md) 섹션을 참조하세요.
## 어떤 GitHub Actions를 사용할 수 있나요?
CodeCatalyst 콘솔을 통해 사용 가능한 모든 GitHub 작업과 [GitHub Marketplace](https://github.com/marketplace/actions)에서 사용 가능한 모든 GitHub 작업을 사용할 수 있습니다. Marketplace에서 GitHub 작업을 사용하기로 결정한 경우 다음 [제한](#integrations-github-actions-limitations) 사항에 유의하세요.
## CodeCatalyst의 GitHub Actions 제한 사항
+ GitHub Actions는 CodeCatalyst [Lambda 컴퓨팅 유형](workflows-working-compute.md#compute.types)에 사용할 수 없습니다.
+ GitHub Actions는 이전 도구를 포함하는 [2022년 11월](build-images.md#build.previous-image) 런타임 환경 Docker 이미지에서 실행됩니다. 사용할 이미지 및 도구에 대한 자세한 내용은 [런타임 환경 이미지 지정](build-images.md) 섹션을 참조하세요.
+ 내부적으로 [`github` 컨텍스트](https://docs.github.com/en/actions/learn-github-actions/contexts#github-context)를 사용하거나 GitHub 관련 리소스를 참조하는 GitHub Actions는 CodeCatalyst에서 지원되지 않습니다. 예를 들어 다음 작업은 CodeCatalyst에서 작동하지 않습니다.
+ GitHub 리소스를 추가, 변경 또는 업데이트하려는 작업입니다. 예를 들어 풀 요청을 업데이트하거나 GitHub에서 문제를 생성하는 작업이 있습니다.
+ [https://github.com/actions](https://github.com/actions) 나열된 거의 모든 작업이 이에 해당합니다.
+ [Docker 컨테이너 작업](https://docs.github.com/en/actions/creating-actions/about-custom-actions#docker-container-actions)인 GitHub Actions는 작동하지만, 빌드 프로젝트는 기본 Docker 사용자(루트)가 실행해야 합니다. 작업을 user 1001로 실행하지 않습니다. (작성 시점에서 사용자 user 1001은 GitHub 에서 작동하지만 CodeCatalyst에서는 작동하지 않습니다.) 자세한 내용은 [GitHub Actions에 대한 Dockerfile 지원](https://docs.github.com/en/actions/creating-actions/dockerfile-support-for-github-actions)의 [사용자](https://docs.github.com/en/actions/creating-actions/dockerfile-support-for-github-actions#user) 항목을 참조하세요.
CodeCatalyst 콘솔을 통해 사용할 수 있는 GitHub Actions 목록은 [큐레이션된 GitHub 작업 추가](integrations-github-action-add-curated.md) 섹션을 참조하세요.
## GitHub 작업(상위 단계)을 추가하려면 어떻게 해야 하나요?
GitHub 작업을 CodeCatalyst 워크플로에 추가하는 간략한 단계는 다음과 같습니다.
1. CodeCatalyst 프로젝트에서 **워크플로를 생성**합니다. 워크플로에서는 애플리케이션을 빌드, 테스트 및 배포하는 방법을 정의합니다. 자세한 내용은 [워크플로 시작하기](workflows-getting-started.md) 섹션을 참조하세요.
1. 워크플로에서 **큐레이션된 GitHub Actions를 추가**하거나 **GitHub Actions** 작업을 추가합니다.
1. 다음 중 하나를 수행할 수 있습니다.
+ 큐레이션된 작업을 추가하기로 선택한 경우 구성합니다. 자세한 내용은 [큐레이션된 GitHub 작업 추가](integrations-github-action-add-curated.md) 섹션을 참조하세요.
+ 큐레이션되지 않은 작업을 추가하기로 선택한 경우 **GitHub Actions** 작업 내에서 **GitHub Actions의 YAML 코드**를 붙여넣습니다. 이 코드는 [GitHub Marketplace](https://github.com/marketplace/actions)에서 선택한 GitHub 작업의 세부 정보 페이지에서 찾을 수 있습니다. CodeCatalyst에서 작동하려면 코드를 약간 수정해야 할 수 있습니다. 자세한 내용은 ['GitHub Actions' 작업 추가](integrations-github-action-add.md) 섹션을 참조하세요.
1. (선택 사항) 워크플로 내에 빌드 및 테스트 작업과 같은 **다른 작업을 추가**합니다. 자세한 내용은 [워크플로를 사용하여 빌드, 테스트 및 배포워크플로를 사용하여 빌드, 테스트 및 배포](workflow.md) 섹션을 참조하세요.
1. 트리거를 통해 **워크플로를 수동으로 또는 자동으로 시작**합니다. 워크플로는 GitHub 작업과 워크플로의 기타 작업을 실행합니다. 자세한 내용은 [워크플로 수동 실행 시작](workflows-manually-start.md) 섹션을 참조하세요.
자세한 단계는 다음을 참조하세요.
+ [큐레이션된 GitHub 작업 추가](integrations-github-action-add-curated.md).
+ ['GitHub Actions' 작업 추가](integrations-github-action-add.md).
## GitHub 작업은 GitHub에서 실행되나요?
아니요. GitHub 작업은 CodeCatalyst의 [런타임 환경 이미지](workflows-working-compute.md)를 사용하여 CodeCatalyst에서 실행됩니다.
## GitHub 워크플로도 사용할 수 있나요?
아니요.
## 'GitHub Actions' 작업에 사용되는 런타임 이미지
CodeCatalyst **GitHub Actions** 작업은 [2022년 11월 이미지](build-images.md#build.previous-image)에서 실행됩니다. 자세한 내용은 [활성 이미지](build-images.md#build-curated-images) 섹션을 참조하세요.
# 자습서: GitHub 작업을 사용한 린트 코드
이 자습서에서는 Amazon CodeCatalyst 워크플로에 [Super-Linter GitHub 작업](https://github.com/marketplace/actions/super-linter)을 추가합니다. Super-Linter 작업은 코드를 검사하고, 코드에 오류가 있는 영역, 서식 문제, 의심스러운 구문을 찾은 다음, 결과를 CodeCatalyst 콘솔에 출력합니다. 워크플로에 린터를 추가한 후 워크플로를 실행하여 샘플 Node.js 애플리케이션(`app.js`)을 린트합니다. 그런 다음 보고된 문제를 수정하고 워크플로를 다시 실행하여 수정 사항이 제대로 작동하는지 확인합니다.
**작은 정보**
[CloudFormation 템플릿](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html)과 같은 YAML 파일을 린트하기 위해 Super-Linter를 사용하는 것이 좋습니다.
**Topics**
+ [사전 조건](#integrations-github-action-tutorial-prereqs)
+ [1단계: 소스 리포지토리 생성](#integrations-github-action-tutorial-create-source-repo)
+ [2단계: app.js 파일 추가](#integrations-github-action-tutorial-add-appjs)
+ [3단계: Super-Linter 작업을 실행하는 워크플로 생성](#integrations-github-action-tutorial-create-workflow)
+ [4단계: Super-Linter에서 발견한 문제 해결](#integrations-github-action-tutorial-fix-probs)
+ [정리](#integrations-github-action-tutorial-cleanup)
## 사전 조건
시작하려면 다음이 필요합니다.
+ 가 연결된 CodeCatalyst **스페이스**입니다 AWS 계정. 자세한 내용은 [스페이스 생성](spaces-create.md) 단원을 참조하십시오.
+ CodeCatalyst 스페이스의 이름이 `codecatalyst-linter-project`인 빈 프로젝트로. **처음부터 시작** 옵션을 선택하여 이 프로젝트를 생성합니다.
```
```
자세한 내용은 [Amazon CodeCatalyst에서 빈 프로젝트 생성](projects-create.md#projects-create-empty) 섹션을 참조하세요.
## 1단계: 소스 리포지토리 생성
이 단계에서는 CodeCatalyst에 소스 리포지토리를 생성합니다. 이 리포지토리를 사용하여 이 자습서의 샘플 애플리케이션 소스 파일인 `app.js`를 저장합니다.
소스 리포지토리에 대한 자세한 정보는 [소스 리포지토리 생성](source-repositories-create.md) 섹션을 참조하세요.
**소스 리포지토리를 생성하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. `codecatalyst-linter-project` 프로젝트로 이동합니다.
1. 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다.
1. **리포지토리 추가**를 선택하고 **리포지토리 생성**을 선택합니다.
1. **리포지토리 이름**에 다음과 같이 입력합니다.
```
codecatalyst-linter-source-repository
```
1. **생성(Create)**을 선택합니다.
## 2단계: app.js 파일 추가
이 단계에서는 원본 리포지토리에 `app.js` 파일을 추가합니다. `app.js`에는 린터에서 찾을 수 있는 몇 가지 실수가 있는 함수 코드가 포함되어 있습니다.
**app.js 파일을 추가하려면**
1. CodeCatalyst 콘솔에서 `codecatalyst-linter-project` 프로젝트를 선택합니다.
1. 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다.
1. 소스 리포지토리 목록에서 `codecatalyst-linter-source-repository` 리포지토리를 선택합니다.
1. **파일**에서 **파일 생성**을 선택합니다.
1. 다음 코드를 텍스트 상자에 입력합니다.
```
// const axios = require('axios')
// const url = 'http://checkip.amazonaws.com/';
let response;
/**
*
* Event doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html#api-gateway-simple-proxy-for-lambda-input-format
* @param {Object} event - API Gateway Lambda Proxy Input Format
*
* Context doc: https://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-context.html
* @param {Object} context
*
* Return doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html
* @returns {Object} object - API Gateway Lambda Proxy Output Format
*
*/
exports.lambdaHandler = async (event, context) => {
try {
// const ret = await axios(url);
response = {
statusCode: 200,
'body': JSON.stringify({
message: 'hello world'
// location: ret.data.trim()
})
}
} catch (err) {
console.log(err)
return err
}
return response
}
```
1. **파일 이름**에 `app.js`를 입력합니다. 다른 기본 옵션을 유지합니다.
1. **커밋**을 선택합니다.
`app.js` 새 역할이 생성되었습니다.
## 3단계: Super-Linter 작업을 실행하는 워크플로 생성
이 단계에서는 코드를 소스 리포지토리로 푸시할 때 Super-Linter 작업을 실행하는 워크플로를 생성합니다. 워크플로는 YAML 파일에 정의한 다음 구성 요소로 구성됩니다.
+ **트리거** - 이 트리거는 소스 리포지토리에 변경 사항을 푸시할 때 워크플로 실행을 자동으로 시작합니다. 트리거에 대한 자세한 내용은 [트리거를 사용하여 워크플로 실행 자동 시작](workflows-add-trigger.md) 주제를 참조하세요.
+ **'GitHub Actions' 작업** - 트리거 시 **GitHub Actions** 작업은 Super-Linter 작업을 실행하여 소스 리포지토리의 모든 파일을 검사합니다. 리터에서 문제를 발견하면 워크플로 작업이 실패합니다.
**Super-Linter 작업을 실행하는 워크플로를 생성하려면**
1. CodeCatalyst 콘솔에서 `codecatalyst-linter-project` 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. **워크플로 생성**을 선택합니다.
1. **소스 리포지토리**에서 `codecatalyst-linter-source-repository`을 선택합니다.
1. **브랜치**에서 `main`을 선택합니다.
1. **생성(Create)**을 선택합니다.
1. YAML 샘플 코드를 삭제합니다.
1. 다음 YAML을 추가합니다:
```
Name: codecatalyst-linter-workflow
SchemaVersion: "1.0"
Triggers:
- Type: PUSH
Branches:
- main
Actions:
SuperLinterAction:
Identifier: aws/github-actions-runner@v1
Configuration:
Steps:
github-action-code
```
이 절차의 다음 단계에 설명된 대로 앞의 코드에서 *github-action-code*를 Super-Linter 작업 코드로 바꿉니다.
1. GitHub Marketplace의 [Super-Linter 페이지로](https://github.com/marketplace/actions/super-linter) 이동합니다.
1. `steps:`(소문자)에서 코드를 찾아 CodeCatalyst 워크플로의 `Steps:`(대문자)에 붙여 넣습니다.
다음 코드와 같이 CodeCatalyst 표준에 맞게 GitHub 작업 코드를 조정합니다.
이제 CodeCatalyst 워크플로는 다음과 같습니다.
```
Name: codecatalyst-linter-workflow
SchemaVersion: "1.0"
Triggers:
- Type: PUSH
Branches:
- main
Actions:
SuperLinterAction:
Identifier: aws/github-actions-runner@v1
Configuration:
Steps:
- name: Lint Code Base
uses: github/super-linter@v4
env:
VALIDATE_ALL_CODEBASE: "true"
DEFAULT_BRANCH: main
```
1. (선택 사항) 커밋하기 전에 YAML 코드가 유효한지 확인하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 **커밋 메시지**를 입력한 다음 `codecatalyst-linter-source-repository`**리포지토리**를 선택하고 **커밋**을 다시 선택합니다.
이제 워크플로를 생성했습니다. 워크플로 상단에 정의된 트리거로 인해 워크플로 실행이 자동으로 시작됩니다.
**진행 중인 워크플로 실행을 보려면**
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 방금 생성한 `codecatalyst-linter-workflow` 워크플로를 선택합니다.
1. 워크플로 다이어그램에서 **SuperLinterAction**을 선택합니다.
1. 작업이 실패할 때까지 기다립니다. 이 실패는 코드에서 linter가 문제를 발견했기 때문에 예상됩니다.
1. CodeCatalyst 콘솔을 열어 두고 [4단계: Super-Linter에서 발견한 문제 해결](#integrations-github-action-tutorial-fix-probs)로 이동합니다.
## 4단계: Super-Linter에서 발견한 문제 해결
Super-Linter는 `app.js` 코드와 소스 리포지토리에 포함된 `README.md` 파일에서 문제를 발견했어야 합니다.
**린터에서 발견된 문제를 해결하려면**
1. CodeCatalyst 콘솔에서 **로그** 탭을 선택한 다음 **Lint Code Base**를 선택합니다.
생성된 슈퍼 린터 작업이 표시되는 로그입니다.
1. 슈퍼 린터 로그에서 90행을 따라 아래로 스크롤하면 문제의 시작을 찾을 수 있습니다. 다음처럼 보일 것입니다.
```
/github/workspace/hello-world/app.js:3:13: Extra semicolon.
/github/workspace/hello-world/app.js:9:92: Trailing spaces not allowed.
/github/workspace/hello-world/app.js:21:7: Unnecessarily quoted property 'body' found.
/github/workspace/hello-world/app.js:31:1: Expected indentation of 2 spaces but found 4.
/github/workspace/hello-world/app.js:32:2: Newline required at end of file but not found.
```
1. 소스 리포지토리에서 `app.js` 및 `README.md`를 수정하고 변경 사항을 커밋합니다.
**작은 정보**
`README.md`를 수정하려면 다음과 같이 코드 블록에 `markdown`을 추가합니다.
```
```markdown
Setup examples:
...
```
```
변경하면 다른 워크플로가 자동으로 실행됩니다. 워크플로가 완료될 때까지 기다립니다. 모든 문제를 해결한 경우 워크플로가 성공해야 합니다.
## 정리
CodeCatalyst에서 정리하여 환경에서 이 자습서의 트레이스를 제거합니다.
**CodeCatalyst에서 정리하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. `codecatalyst-linter-source-repository`를 삭제합니다.
1. `codecatalyst-linter-workflow`를 삭제합니다.
이 자습서에서는 일부 코드를 린트하기 위해 CodeCatalyst 워크플로에 Super-Linter GitHub 작업을 추가하는 방법을 배웠습니다.
# 'GitHub Actions' 작업 추가
***GitHub Actions*** 작업은 GitHub Actions를 래핑하고 CodeCatalyst 워크플로와 호환되는 *CodeCatalyst 작업*입니다.
자세한 내용은 [GitHub Actions와 통합](integrations-github-actions.md) 섹션을 참조하세요.
워크플로에 **GitHub Actions** 작업을 추가하려면 다음 단계를 따르세요.
**작은 정보**
**GitHub Actions** 작업을 사용하는 방법을 보여주는 자습서는 [자습서: GitHub 작업을 사용한 린트 코드](integrations-github-action-tutorial.md) 섹션을 참조하세요.
------
#### [ Visual ]
**시각적 편집기를 사용하여 'GitHub Actions' 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **GitHub**를 선택합니다.
1. **GitHub Actions** 작업을 검색하고 다음 중 하나를 수행합니다.
+ 더하기 기호(**\$1**)를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
또는
+ **GitHub Actions**를 선택합니다. 작업 세부 정보 대화 상자가 나타납니다. 이 대화 상자에서 다음을 수행합니다.
+ (선택 사항) **소스 보기**를 선택하여 [작업의 소스 코드를 봅니다](workflows-view-source.md#workflows-view-source.title).
+ **워크플로에 추가**를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
1. **입력** 및 **구성** 탭에서 필요에 따라 필드를 작성합니다. 각 필드의 설명은 ['GitHub Actions' 작업 YAML](github-action-ref.md) 섹션을 참조하세요. 이 참조는 YAML 및 시각적 편집기 모두에 나타나는 각 필드(및 해당 YAML 속성 값)에 대한 자세한 정보를 제공합니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**YAML 편집기를 사용하여 'GitHub Actions' 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **GitHub**를 선택합니다.
1. **GitHub Actions** 작업을 검색하고 다음 중 하나를 수행합니다.
+ 더하기 기호(**\$1**)를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
또는
+ **GitHub Actions**를 선택합니다. 작업 세부 정보 대화 상자가 나타납니다. 이 대화 상자에서 다음을 수행합니다.
+ (선택 사항) **소스 보기**를 선택하여 [작업의 소스 코드를 봅니다](workflows-view-source.md#workflows-view-source.title).
+ **워크플로에 추가**를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
1. 필요에 따라 YAML 코드의 속성을 수정합니다. 사용 가능한 각 속성에 대한 설명은 ['GitHub Actions' 작업 YAML](github-action-ref.md)에서 볼 수 있습니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
## 'GitHub Actions' 작업 정의
**GitHub Actions** 작업은 워크플로 정의 파일 내의 YAML 속성 집합으로 정의됩니다. 이러한 속성에 대한 자세한 내용은 [워크플로 YAML 정의](workflow-reference.md)의 ['GitHub Actions' 작업 YAML](github-action-ref.md) 섹션을 참조하세요.
# 큐레이션된 GitHub 작업 추가
*큐레이션된 GitHub 작업*은 CodeCatalyst 콘솔에서 사용할 수 있는 GitHub 작업이며 CodeCatalyst 워크플로 내에서 GitHub 작업을 사용하는 방법의 예입니다.
큐레이션된 GitHub Actions는 CodeCatalyst에서 만든 [**GitHub Actions** 작업](integrations-github-action-add.md)에 래핑되며 `aws/github-actions-runner@v1` 식별자로 식별됩니다. 예를 들어 큐레이션된 GitHub 작업인 [TruffleHog OSS](https://github.com/marketplace/actions/trufflehog-oss)는 다음과 같습니다.
```
Actions:
TruffleHogOSS_e8:
Identifier: aws/github-actions-runner@v1
Inputs:
Sources:
- WorkflowSource # This specifies that the action requires this Workflow as a source
Configuration:
Steps:
- uses: trufflesecurity/trufflehog@v3.16.0
with:
path: ' ' # Required; description: Repository path
base: ' ' # Required; description: Start scanning from here (usually main branch).
head: ' ' # Optional; description: Scan commits until here (usually dev branch).
extra_args: ' ' # Optional; description: Extra args to be passed to the trufflehog cli.
```
이전 코드에서 CodeCatalyst **GitHub Actions** 작업(`aws/github-actions-runner@v1`로 식별됨)은 TruffleHog OSS 작업(`trufflesecurity/trufflehog@v3.16.0`로 식별됨)을 래핑하여 CodeCatalyst 워크플로에서 작동하도록 합니다.
이 작업을 구성하려면 `with:`의 빈 문자열을 고유한 값으로 바꿉니다. 예:
```
Actions:
TruffleHogOSS_e8:
Identifier: aws/github-actions-runner@v1
Inputs:
Sources:
- WorkflowSource # This specifies that the action requires this Workflow as a source
Configuration:
Steps:
- uses: trufflesecurity/trufflehog@v3.16.0
with:
path: ./
base: main # Required; description: Start scanning from here (usually main branch).
head: HEAD # Optional; description: Scan commits until here (usually dev branch).
extra_args: '‐‐debug ‐‐only-verified' # Optional; description: Extra args to be passed to the trufflehog cli.
```
큐레이션된 GitHub 작업을 워크플로에 추가하려면 다음 절차를 사용합니다. CodeCatalyst 워크플로에서 GitHub Actions를 사용하는 방법에 대한 일반적인 내용은 [GitHub Actions와 통합](integrations-github-actions.md) 섹션을 참조하세요.
**참고**
큐레이션된 작업 목록 중에 GitHub Actions가 표시되지 않는 경우에도 **GitHub Actions** 작업을 사용하여 워크플로에 추가할 수 있습니다. 자세한 내용은 ['GitHub Actions' 작업 추가](integrations-github-action-add.md) 섹션을 참조하세요.
------
#### [ Visual ]
**시각적 편집기를 사용하여 큐레이션된 GitHub 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **GitHub**를 선택합니다.
1. GitHub 작업을 찾아보거나 검색하고 다음 중 하나를 수행합니다.
+ 더하기 기호(**\$1**)를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
또는
+ GitHub 작업의 이름을 선택합니다. 작업 세부 정보 대화 상자가 나타납니다. 이 대화 상자에서 다음을 수행합니다.
+ (선택 사항) **소스 보기**를 선택하여 [작업의 소스 코드를 봅니다](workflows-view-source.md#workflows-view-source.title).
+ **워크플로에 추가**를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
1. **입력,** **구성** 및 **출력** 탭에서 필요에 따라 필드를 작성합니다. 각 필드의 설명은 ['GitHub Actions' 작업 YAML](github-action-ref.md) 섹션을 참조하세요. 이 참조는 **GitHub Actions** 작업에 사용할 수 있는 각 필드(및 해당 YAML 속성 값)에 대한 자세한 정보를 제공합니다. 이는 YAML 및 시각적 편집기 모두에 표시됩니다.
큐레이션된 GitHub 작업에서 사용할 수 있는 구성 옵션에 대한 자세한 내용은 해당 설명서를 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**YAML 편집기를 사용하여 큐레이션된 GitHub 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **GitHub**를 선택합니다.
1. GitHub 작업을 찾아보거나 검색하고 다음 중 하나를 수행합니다.
+ 더하기 기호(**\$1**)를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
또는
+ GitHub 작업의 이름을 선택합니다. 작업 세부 정보 대화 상자가 나타납니다. 이 대화 상자에서 다음을 수행합니다.
+ (선택 사항) **소스 보기**를 선택하여 [작업의 소스 코드를 봅니다](workflows-view-source.md#workflows-view-source.title).
+ **워크플로에 추가**를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
1. 필요에 따라 YAML 코드의 속성을 수정합니다. **GitHub Actions** 작업에 사용할 수 있는 각 속성에 대한 설명은 ['GitHub Actions' 작업 YAML](github-action-ref.md)에 나와 있습니다.
큐레이션된 GitHub 작업에서 사용할 수 있는 구성 옵션에 대한 자세한 내용은 해당 설명서를 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# GitHub 출력 파라미터 내보내기
CodeCatalyst 워크플로에서 [GitHub 출력 파라미터](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter)를 사용할 수 있습니다.
**참고**
*출력 파라미터*의 또 다른 단어는 *변수*입니다. GitHub는 설명서에서 용어 *출력 파라미터*를 사용하기 때문에 이 용어도 사용할 것입니다.
다른 CodeCatalyst 워크플로 작업에서 사용할 수 있도록 GitHub 작업에서 GitHub 출력 파라미터를 내보내려면 다음 지침을 사용합니다.
**GitHub 출력 파라미터를 내보내려면**
1. 워크플로를 열고 **편집**을 선택합니다. 자세한 내용은 [워크플로 생성](workflows-create-workflow.md) 섹션을 참조하세요.
1. 내보내려는 출력 파라미터를 생성하는 **GitHub Actions** 작업에서 다음과 같은 기본 `Variables` 속성이 있는 `Outputs` 섹션을 추가합니다.
```
Actions:
MyGitHubAction:
Identifier: aws/github-actions-runner@v1
Outputs:
Variables:
- 'step-id_output-name'
```
다음과 같이 바꿉니다.
+ *step-id*를 GitHub 작업 `steps` 섹션의 `id:` 속성 값으로 바꿉니다.
+ *output-name*을 GitHub 출력 파라미터의 이름으로 바꿉니다.
**예시**
다음 예시에서는 `SELECTEDCOLOR` GitHub 출력 파라미터를 내보내는 방법을 보여줍니다.
```
Actions:
MyGitHubAction:
Identifier: aws/github-actions-runner@v1
Outputs:
Variables:
- 'random-color-generator_SELECTEDCOLOR'
Configuration:
Steps:
- name: Set selected color
run: echo "SELECTEDCOLOR=green" >> $GITHUB_OUTPUT
id: random-color-generator
```
# GitHub 출력 파라미터 참조
다음 지침을 사용하여 GitHub 출력 파라미터를 참조합니다.
**GitHub 출력 파라미터를 참조하려면**
1. [GitHub 출력 파라미터 내보내기](integrations-github-action-export.md)의 단계를 수행하세요.
이제 GitHub 출력 파라미터를 다른 작업에 사용할 수 있습니다.
1. 출력 파라미터의 `Variables` 값을 기록해 둡니다. 밑줄(\$1)이 포함됩니다.
1. 다음 구문을 사용하여 출력 파라미터를 참조하세요.
```
${action-name.output-name}
```
다음과 같이 바꿉니다.
+ *action-name*을 출력 파라미터를 생성하는 CodeCatalyst **GitHub 작업** 이름으로 바꿉니다(GitHub 작업 `name` 또는 `id`는 사용하지 않습니다).
+ *output-name* 을 앞서 적어 둔 출력 파라미터의 `Variables` 값으로 바꿉니다.
**예제**
```
BuildActionB:
Identifier: aws/build@v1
Configuration:
Steps:
- Run: echo ${MyGitHubAction.random-color-generator_SELECTEDCOLOR}
```
**컨텍스트가 있는 예시**
다음 예시에서는 `GitHubActionA`에서 `SELECTEDCOLOR` 변수를 설정하고 출력한 다음 `BuildActionB`에서 참조하는 방법을 보여줍니다.
```
Actions:
GitHubActionA:
Identifier: aws/github-actions-runner@v1
Configuration:
Steps:
- name: Set selected color
run: echo "SELECTEDCOLOR=green" >> $GITHUB_OUTPUT
id: random-color-generator
Outputs:
Variables:
- 'random-color-generator_SELECTEDCOLOR'
BuildActionB:
Identifier: aws/build@v1
Configuration:
Steps:
- Run: echo ${GitHubActionA.random-color-generator_SELECTEDCOLOR}
```
# 'GitHub Actions' 작업 YAML
다음은 **GitHub Actions** 작업의 YAML 정의입니다.
이 작업 정의는 더 광범위한 워크플로 정의 파일 내의 섹션으로 존재합니다. 이 파일에 대한 자세한 내용은 [워크플로 YAML 정의](workflow-reference.md)을 참조합니다.
다음 코드에서 YAML 속성을 선택하면 설명이 표시됩니다.
**참고**
이어지는 대부분의 YAML 속성에는 시각적 편집기에 해당 UI 요소가 있습니다. UI 요소를 찾으려면 **Ctrl\$1F**를 사용합니다. 요소가 연결된 YAML 속성과 함께 나열됩니다.
```
# The workflow definition starts here.
# See 최상위 속성 for details.
Name: MyWorkflow
SchemaVersion: 1.0
Actions:
# The action definition starts here.
action-name:
Identifier: aws/github-actions-runner@v1
DependsOn:
- dependent-action-name-1
Compute:
Fleet: fleet-name
Timeout: timeout-minutes
Environment:
Name: environment-name
Connections:
- Name: account-connection-name
Role: iam-role-name
Inputs:
Sources:
- source-name-1
- source-name-2
Artifacts:
- artifact-name
Variables:
- Name: variable-name-1
Value: variable-value-1
- Name: variable-name-2
Value: variable-value-2
Outputs:
Artifacts:
- Name: output-artifact-1
Files:
- github-output/artifact-1.jar
- "github-output/build*"
- Name: output-artifact-2
Files:
- github-output/artifact-2.1.jar
- github-output/artifact-2.2.jar
Variables:
- variable-name-1
- variable-name-2
AutoDiscoverReports:
Enabled: true | false
ReportNamePrefix: AutoDiscovered
IncludePaths:
- "**/*"
ExcludePaths:
- node_modules/cdk/junit.xml
SuccessCriteria:
PassRate: percent
LineCoverage: percent
BranchCoverage: percent
Vulnerabilities:
Severity: CRITICAL|HIGH|MEDIUM|LOW|INFORMATIONAL
Number: whole-number
Reports:
report-name-1:
Format: format
IncludePaths:
- "*.xml"
ExcludePaths:
- report2.xml
- report3.xml
SuccessCriteria:
PassRate: percent
LineCoverage: percent
BranchCoverage: percent
Vulnerabilities:
Severity: CRITICAL|HIGH|MEDIUM|LOW|INFORMATIONAL
Number: whole-number
Configuration
Steps:
- github-actions-code
```
## action-name
(필수)
작업 이름을 지정합니다. 워크플로 내의 모든 작업 이름은 고유해야 합니다. 작업 이름은 영숫자 문자(a-z, A-Z, 0-9), 하이픈(-) 및 밑줄(\$1)로 제한됩니다. 스페이스은 허용되지 않습니다. 작업 이름에서 특수 문자와 공백을 활성화하는 데 따옴표를 사용할 수 없습니다.
해당 UI: 구성 탭/*action-name*
## Identifier
(*action-name*/**Identifier**)
작업을 식별합니다. 버전을 변경하려는 경우가 아니면 이 속성을 변경하지 마세요. 자세한 내용은 [사용할 작업 버전 지정](workflows-action-versions.md) 섹션을 참조하세요.
`aws/github-actions-runner@v1`를 **GitHub Actions** 작업에 사용합니다.
해당 UI: 워크플로 다이어그램/*action-name */**aws/github-actions-runner@v1** 레이블
## DependsOn
(*action-name*/**DependsOn**)
(선택 사항)
이 작업을 실행하기 위해 성공적으로 실행해야 하는 작업, 작업 그룹 또는 게이트를 지정합니다.
'depends on' 함수에 대한 자세한 내용은 [작업 순서 지정](workflows-depends-on.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**의존 - 선택 사항**
## Compute
(*action-name*/**Compute**)
(선택 사항)
워크플로 작업을 실행하는 데 사용되는 컴퓨팅 엔진입니다. 워크플로 수준 또는 작업 수준에서 컴퓨팅을 지정할 수 있지만 둘 다 지정할 수는 없습니다. 워크플로 수준에서 지정하면 컴퓨팅 구성이 워크플로에 정의된 모든 작업에 적용됩니다. 워크플로 수준에서는 동일한 인스턴스에서 여러 작업을 실행할 수도 있습니다. 자세한 내용은 [작업 간에 컴퓨팅 공유](compute-sharing.md) 섹션을 참조하세요.
해당 UI: *없음*
## Fleet
(*action-name*/Compute/**Fleet**)
(선택 사항)
워크플로 또는 워크플로 작업을 실행할 시스템 또는 플릿을 지정합니다. 온디맨드 플릿의 경우 작업이 시작되면 워크플로가 필요한 리소스를 프로비저닝하고 작업이 완료되면 시스템이 파괴됩니다. 온디맨드 플릿의 예시: `Linux.x86-64.Large`, `Linux.x86-64.XLarge`. 온디맨드 플릿에 대한 자세한 내용은 [온디맨드 플릿 속성](workflows-working-compute.md#compute.on-demand) 섹션을 참조하세요.
프로비저닝된 플릿을 사용하면 워크플로 작업을 실행하도록 전용 시스템 세트를 구성할 수 있습니다. 이러한 시스템은 유휴 상태로 유지되므로 작업을 즉시 처리할 수 있습니다. 프로비저닝된 플릿에 대한 자세한 내용은 [프로비저닝된 플릿 속성](workflows-working-compute.md#compute.provisioned-fleets) 섹션을 참조하세요.
`Fleet` 생략 시 기본값은 `Linux.x86-64.Large`입니다.
해당 UI: 구성 탭/**컴퓨팅 플릿 - 선택 사항**
## Timeout
(*action-name*/**Timeout**)
(선택 사항)
CodeCatalyst가 작업을 종료하기 전에 작업을 실행할 수 있는 시간을 분(YAML 편집기) 또는 시간 및 분(시각적 편집기) 단위로 지정합니다. 최소값은 5분이고 최대값은 [CodeCatalyst의 워크플로 할당량](workflows-quotas.md)에 설명되어 있습니다. 기본 제한 시간은 최대 제한 시간과 동일합니다.
해당 UI: 구성 탭/**제한 시간 - 선택 사항 **
## Environment
(*action-name*/**Environment**)
(선택 사항)
작업에 사용할 CodeCatalyst 환경을 지정합니다. 작업은 선택한 환경에 지정된 AWS 계정 및 선택적 Amazon VPC에 연결됩니다. 작업은 환경에 지정된 기본 IAM 역할을 사용하여에 연결하고 [Amazon VPC 연결](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)에 지정된 IAM 역할을 AWS 계정사용하여 Amazon VPC에 연결합니다.
**참고**
기본 IAM 역할에 작업에 필요한 권한이 없는 경우 다른 역할을 사용하도록 작업을 구성할 수 있습니다. 자세한 내용은 [작업의 IAM 역할 변경](deploy-environments-switch-role.md) 섹션을 참조하세요.
환경에 대한 자세한 내용은 [AWS 계정 및 VPCs에 배포](deploy-environments.md) 및 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
해당 UI: 구성 탭/**환경**
## Name
(*action-name*/Environment/**Name**)
([Environment](#github.environment) 포함 시 필수)
작업과 연결하려는 기존 환경의 이름을 지정합니다.
해당 UI: 구성 탭/**환경**
## Connections
(*action-name*/Environment/**Connections**)
(선택 사항)
작업과 연결할 계정 연결을 지정합니다. `Environment`에서 계정 연결을 최대 1개까지 지정할 수 있습니다.
계정 연결을 지정하지 않는 경우:
+ 작업은 CodeCatalyst 콘솔의 환경에 지정된 AWS 계정 연결 및 기본 IAM 역할을 사용합니다. 환경에 계정 연결 및 기본 IAM 역할을 추가하는 방법에 대한 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
+ 기본 IAM 역할에는 작업에 필요한 정책 및 권한이 포함되어야 합니다. 이러한 정책 및 권한이 무엇인지 확인하려면 작업의 YAML 정의 설명서에서 **역할** 속성에 대한 설명을 참조하세요.
계정 연결에 대한 자세한 정보는 [연결된를 사용하여 AWS 리소스에 대한 액세스 허용 AWS 계정](ipa-connect-account.md) 섹션을 참조하세요. 환경에 계정 연결을 추가하는 방법에 대한 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
해당 UI: 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
## Name
(*action-name*/Environment/Connections/**Name**)
([Connections](#github.environment.connections) 포함 시 필수)
계정 연결의 이름을 지정합니다.
해당 UI: 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
## Role
(*action-name*/Environment/Connections/**Role**)
([Connections](#github.environment.connections) 포함 시 필수)
Amazon S3 및 Amazon ECR과 같은 AWS 서비스에 액세스하고 운영하기 위해 이 작업이 사용하는 IAM 역할의 이름을 지정합니다. 이 역할이 스페이스의 AWS 계정 연결에 추가되었는지 확인합니다. 계정 연결에 IAM 역할을 추가하려면 [계정 연결에 IAM 역할 추가](ipa-connect-account-addroles.md) 섹션을 참조하세요.
IAM 역할을 지정하지 않으면 작업은 CodeCatalyst 콘솔의 [환경](deploy-environments.md)에 나열된 기본 IAM 역할을 사용합니다. 환경에서 기본 역할을 사용하는 경우 다음 정책이 있는지 확인합니다.
**참고**
이 작업에서 `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할을 사용할 수 있습니다. 이에 대한 자세한 내용은 [계정 및 스페이스의 **CodeCatalystWorkflowDevelopmentRole-*spaceName*** 역할 생성](ipa-iam-roles.md#ipa-iam-roles-service-create) 섹션을 참조하세요. `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할에 보안 위험을 초래할 수 있는 전체 액세스 권한이 있음을 이해합니다. 보안에 대한 우려가 적은 자습서 및 시나리오에서만 이 역할을 사용하는 것이 좋습니다.
**주의**
권한을 **GitHub 작업** 작업에 필요한 권한으로 제한합니다. 더 광범위한 권한을 가진 역할을 사용하면 보안 위험이 발생할 수 있습니다.
해당 UI: 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
## Inputs
(*action-name*/**Inputs**)
(선택 사항)
이 `Inputs` 섹션에서는 워크플로 실행 중에 작업에 필요한 데이터를 정의합니다.
**참고**
**GitHub Actions** 작업당 최대 4개의 입력(소스 1개 및 아티팩트 3개)이 허용됩니다. 변수는 이 합계에 포함되지 않습니다.
서로 다른 입력(소스 및 아티팩트)에 있는 파일을 참조해야 하는 경우 소스 입력은 기본 입력이고 아티팩트는 보조 입력입니다. 보조 입력의 파일에 대한 참조는 특수 접두사를 사용하여 기본 입력에서 파일을 구분합니다. 자세한 내용은 [예시: 여러 아티팩트에서 파일 참조](workflows-working-artifacts-ex.md#workflows-working-artifacts-ex-ref-file)을 참조하세요.
해당 UI: **입력** 탭
## Sources
(*action-name*/Inputs/**Sources**)
(선택 사항)
작업에 필요한 소스 리포지토리를 나타내는 레이블을 지정합니다. 현재 지원되는 유일한 레이블은 워크플로 정의 파일이 저장되는 소스 리포지토리를 나타내는 `WorkflowSource`입니다.
소스를 생략하는 경우 `action-name/Inputs/Artifacts` 아래에 하나 이상의 입력 아티팩트를 지정해야 합니다.
소스에 대한 자세한 내용은 [워크플로에 소스 리포지토리 연결](workflows-sources.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**소스 - 선택 사항**
## Artifacts - input
(*action-name*/Inputs/**Artifacts**)
(선택 사항)
이 작업에 대한 입력으로 제공하려는 이전 작업의 아티팩트를 지정합니다. 이러한 아티팩트는 이전 작업에서 출력 아티팩트로 이미 정의되어 있어야 합니다.
입력 아티팩트를 지정하지 않으면 `action-name/Inputs/Sources` 아래에 소스 리포지토리를 하나 이상 지정해야 합니다.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
**참고**
**아티팩트 - 선택적** 드롭다운 목록을 사용할 수 없거나(시각적 편집기) YAML(YAML 편집기)을 검증할 때 오류가 발생하는 경우 작업이 하나의 입력만 지원하기 때문일 수 있습니다. 이 경우 소스 입력을 제거해 보세요.
해당 UI: 입력 탭/**아티팩트 - 선택 사항**
## Variables - input
(*action-name*/Inputs/**Variables**)
(선택 사항)
작업에 사용할 수 있도록 하려는 입력 변수를 정의하는 이름/값 페어의 시퀀스를 지정합니다. 변수 이름은 영숫자 문자(a-z, A-Z, 0-9), 하이픈(-) 및 밑줄(\$1)로 제한됩니다. 스페이스은 허용되지 않습니다. 변수 이름에서 특수 문자와 공백을 활성화하는 데 따옴표를 사용할 수 없습니다.
예시를 비롯한 변수에 대한 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**변수 - 선택 사항**
## Outputs
(*action-name*/**Outputs**)
(선택 사항)
워크플로 실행 중에 작업에 의해 출력되는 데이터를 정의합니다.
해당 UI: **출력** 탭
## Artifacts - output
(*action-name*/Outputs/**Artifacts**)
(선택 사항)
작업에서 생성된 아티팩트의 이름을 지정합니다. 아티팩트 이름은 워크플로 내에서 고유해야 하며 영숫자 문자(a-z, A-Z, 0-9) 및 밑줄(\$1)로 제한됩니다. 공백, 하이픈(-) 및 특수 문자는 허용되지 않습니다. 출력 아티팩트 이름에서 공백, 하이픈 및 기타 특수 문자를 활성화하는 데 따옴표를 사용할 수 없습니다.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
해당 UI: 출력 탭/**아티팩트**
## Name
(*action-name*/Outputs/Artifacts/**Name**)
([Artifacts - output](#github.outputs.artifacts) 포함 시 필수)
작업에서 생성된 아티팩트의 이름을 지정합니다. 아티팩트 이름은 워크플로 내에서 고유해야 하며 영숫자 문자(a-z, A-Z, 0-9) 및 밑줄(\$1)로 제한됩니다. 공백, 하이픈(-) 및 특수 문자는 허용되지 않습니다. 출력 아티팩트 이름에서 공백, 하이픈 및 기타 특수 문자를 활성화하는 데 따옴표를 사용할 수 없습니다.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
해당 UI: 출력 탭/아티팩트/아티팩트 추가/**빌드 아티팩트 이름**
## Files
(*action-name*/Outputs/Artifacts/**Files**)
([Artifacts - output](#github.outputs.artifacts) 포함 시 필수)
CodeCatalyst가 작업으로 출력되는 아티팩트에 포함하는 파일을 지정합니다. 이러한 파일은 실행 시 워크플로 작업에 의해 생성되며 소스 리포지토리에서도 사용할 수 있습니다. 파일 경로는 소스 리포지토리 또는 이전 작업의 아티팩트에 상주할 수 있으며 소스 리포지토리 또는 아티팩트 루트와 관련이 있습니다. glob 패턴을 사용하여 경로를 지정할 수 있습니다. 예시:
+ 빌드 위치 또는 소스 리포지토리 위치의 루트에 있는 단일 파일을 지정하려면 `my-file.jar`를 사용합니다..
+ 하위 디렉터리에 단일 파일을 지정하려면 `directory/my-file.jar` 또는 `directory/subdirectory/my-file.jar`를 사용합니다.
+ 모든 파일을 지정하려면 `"**/*"`를 사용합니다. `**` glob 패턴은 임의의 수의 하위 디렉터리와 일치함을 나타냅니다.
+ `directory`라는 디렉터리에 있는 모든 파일 및 디렉터리를 지정하려면 `"directory/**/*"`를 사용합니다. `**` glob 패턴은 임의의 수의 하위 디렉터리와 일치함을 나타냅니다.
+ `directory`라는 디렉터리의 모든 파일을 지정하되 해당 하위 디렉터리는 지정하지 않으려면 `"directory/*"`를 사용합니다.
**참고**
파일 경로에 별표(`*`) 또는 기타 특수 문자가 하나 이상 포함된 경우 경로를 큰따옴표(`""`)로 묶습니다. 특수 문자에 대한 자세한 내용은 [구문 지침 및 규칙](workflow-reference.md#workflow.terms.syntax.conv) 섹션을 참조하세요.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
**참고**
파일 경로에 접두사를 추가하여 찾을 아티팩트 또는 소스를 나타내야 할 수 있습니다. 자세한 내용은 [소스 리포지토리 파일 참조](workflows-sources-reference-files.md) 및 [아티팩트의 파일 참조](workflows-working-artifacts-refer-files.md) 섹션을 참조하세요.
해당 UI: 출력 탭/아티팩트/아티팩트 추가/**빌드에서 생성된 파일**
## Variables - output
(*action-name*/Outputs/**Variables**)
(선택 사항)
후속 작업에서 사용할 수 있도록 작업을 내보낼 변수를 지정합니다.
예시를 비롯한 변수에 대한 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
해당 UI: 출력 탭/변수/**변수 추가**
## variable-name-1
(*action-name*/Outputs/Variables**variable-name-1**)
(선택 사항)
작업을 내보낼 변수의 이름을 지정합니다. 이 변수는 동일한 작업의 `Inputs` 또는 `Steps` 섹션에 이미 정의되어 있어야 합니다.
예시를 비롯한 변수에 대한 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
해당 UI: 출력 탭/변수/변수 추가/**이름**
## AutoDiscoverReports
(*action-name*/Outputs/**AutoDiscoverReports**)
(선택 사항)
자동 검색 기능의 구성을 정의합니다.
자동 검색을 활성화하면 CodeCatalyst는 작업에 전달된 모든 `Inputs`와 작업 자체에서 생성된 모든 파일을 검색하여 테스트, 코드 적용 범위 및 소프트웨어 구성 분석(SCA) 보고서를 찾습니다. 발견된 각 보고서에 대해 CodeCatalyst는 이를 CodeCatalyst 보고서로 변환합니다. *CodeCatalyst 보고서*는 CodeCatalyst 서비스에 완전히 통합되고 CodeCatalyst 콘솔을 통해 보고 조작할 수 있는 보고서입니다.
**참고**
기본적으로 자동 검색 기능은 모든 파일을 검사합니다. [IncludePaths](#github.reports.includepaths) 또는 [ExcludePaths](#github.reports.excludepaths) 속성을 사용하여 검사할 파일을 제한할 수 있습니다.
해당 UI: *없음*
## Enabled
(*action-name*/Outputs/AutoDiscoverReports/**Enabled**)
(선택 사항)
자동 검색 기능을 활성화하거나 비활성화합니다.
유효한 값은 `true` 또는 `false`입니다.
`Enabled` 생략 시 기본값은 `true`입니다.
해당 UI: 출력 탭/보고서/**자동 검색 보고서**
## ReportNamePrefix
(*action-name*/Outputs/AutoDiscoverReports/**ReportNamePrefix**)
([AutoDiscoverReports](#github.outputs.autodiscover) 포함 및 활성화 시 필수)
연결된 CodeCatalyst 보고서의 이름을 지정하기 위해 CodeCatalyst가 찾는 모든 보고서에 우선하는 접두사를 지정합니다. 예를 들어 접두사를 `AutoDiscovered`로 지정하고 CodeCatalyst가 두 개의 테스트 보고서, `TestSuiteOne.xml` 및 `TestSuiteTwo.xml`를 자동으로 검색하면 연결된 CodeCatalyst 보고서의 이름이 `AutoDiscoveredTestSuiteOne` 및 `AutoDiscoveredTestSuiteTwo`로 지정됩니다.
해당 UI: 출력 탭/보고서/보고서 자동 검색/**보고서 접두사**
## IncludePaths
(*action-name*/Outputs/AutoDiscoverReports/**IncludePaths**)
또는
(*action-name*/Outputs/Reports/*report-name-1*/**IncludePaths**)
([AutoDiscoverReports](#github.outputs.autodiscover) 포함 및 활성화 시 또는 [Reports](#github.configuration.reports) 포함 시 필수)
원시 보고서를 검색할 때 CodeCatalyst에 포함되는 파일 및 파일 경로를 지정합니다. 예를 들어 `"/test/report/*"` 지정 시 CodeCatalyst는 작업에서 `/test/report/*` 디렉터리를 찾는 데 사용되는 전체 [빌드 이미지](build-images.md)를 검색합니다. 해당 디렉터리를 찾으면 CodeCatalyst는 해당 디렉터리에서 보고서를 찾습니다.
**참고**
파일 경로에 별표(`*`) 또는 기타 특수 문자가 하나 이상 포함된 경우 경로를 큰따옴표(`""`)로 묶습니다. 특수 문자에 대한 자세한 내용은 [구문 지침 및 규칙](workflow-reference.md#workflow.terms.syntax.conv) 섹션을 참조하세요.
이 속성이 생략되면 기본값은 `"**/*"`입니다. 즉, 검색에 모든 경로의 모든 파일이 포함됩니다.
**참고**
수동으로 구성된 보고서의 경우 `IncludePaths`는 단일 파일과 일치하는 글로브 패턴이어야 합니다.
해당 UI:
+ 출력 탭/보고서/보고서 자동 검색/'경로 포함/제외'/**경로 포함**
+ 출력 탭/보고서/보고서 수동 구성/*report-name-1*/'경로 포함/제외'/**경로 포함**
## ExcludePaths
(*action-name*/Outputs/AutoDiscoverReports/**ExcludePaths**)
또는
(*action-name*/Outputs/Reports/ *report-name-1*/**ExcludePaths**)
(선택 사항)
원시 보고서를 검색할 때 CodeCatalyst에서 제외하는 파일 및 파일 경로를 지정합니다. 예를 들어 `"/test/my-reports/**/*"` 지정 시 CodeCatalyst는 `/test/my-reports/` 디렉터리의 파일을 검색하지 않습니다. 디렉터리의 모든 파일을 무시하려면 `**/*` glob 패턴을 사용합니다.
**참고**
파일 경로에 별표(`*`) 또는 기타 특수 문자가 하나 이상 포함된 경우 경로를 큰따옴표(`""`)로 묶습니다. 특수 문자에 대한 자세한 내용은 [구문 지침 및 규칙](workflow-reference.md#workflow.terms.syntax.conv) 섹션을 참조하세요.
해당 UI:
+ 출력 탭/보고서/보고서 자동 검색/'경로 포함/제외'/**경로 제외**
+ 출력 탭/보고서/보고서 수동 구성/*report-name-1*/'경로 포함/제외'/**경로 제외**
## SuccessCriteria
(*action-name*/Outputs/AutoDiscoverReports/**SuccessCriteria**)
또는
(*action-name*/Outputs/Reports/ *report-name-1*/**SuccessCriteria**)
(선택 사항)
테스트, 코드 적용 범위, 소프트웨어 구성 분석(SCA) 및 정적 분석(SA) 보고서의 성공 기준을 지정합니다.
자세한 내용은 [보고서의 성공 기준 구성](test-config-action.md#test.success-criteria) 섹션을 참조하세요.
해당 UI:
+ 출력 탭/보고서/보고서 자동 검색/**성공 기준**
+ 출력 탭/보고서/보고서 수동 구성/*report-name-1*/**성공 기준**
## PassRate
(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**PassRate**)
또는
(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**PassRate**)
(선택 사항)
관련 CodeCatalyst 보고서를 통과로 표시하기 위해 통과해야 하는 테스트 보고서의 테스트 비율을 지정합니다. 유효한 값에는 십진수가 포함됩니다. 예시: `50`, `60.5`. 통과율 기준은 테스트 보고서에만 적용됩니다. 테스트 보고서에 대한 자세한 내용은 [테스트 보고서](test-workflow-actions.md#test-reports)의 내용을 참조하세요.
해당 UI:
+ 출력 탭/보고서/보고서 자동 검색/성공 기준/**통과율**
+ 출력 탭/보고서/보고서 수동 구성/*report-name-1*/성공 기준/**통과율**
## LineCoverage
(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**LineCoverage**)
또는
(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**LineCoverage**)
(선택 사항)
연결된 CodeCatalyst 보고서를 통과로 표시하기 위해 다루어야 하는 코드 적용 범위 보고서의 줄 비율을 지정합니다. 유효한 값에는 십진수가 포함됩니다. 예시: `50`, `60.5`. 라인 적용 범위 기준은 코드 적용 범위 보고서에만 적용됩니다. 코드 적용 범위 보고서에 대한 자세한 내용은 [코드 적용 범위 보고서](test-workflow-actions.md#test-code-coverage-reports) 섹션을 참조하세요.
해당 UI:
+ 출력 탭/보고서/보고서 자동 검색/성공 기준/**라인 적용 범위**
+ 출력 탭/보고서/보고서 수동 구성/*report-name-1*/성공 기준/**라인 적용 범위**
## BranchCoverage
(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**BranchCoverage**)
또는
(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**BranchCoverage**)
(선택 사항)
연결된 CodeCatalyst 보고서를 통과로 표시하기 위해 다루어야 하는 코드 적용 범위 보고서의 브랜치 비율을 지정합니다. 유효한 값에는 십진수가 포함됩니다. 예시: `50`, `60.5`. 브랜치 적용 범위 기준은 코드 적용 범위 보고서에만 적용됩니다. 코드 적용 범위 보고서에 대한 자세한 내용은 [코드 적용 범위 보고서](test-workflow-actions.md#test-code-coverage-reports) 섹션을 참조하세요.
해당 UI:
+ 출력 탭/보고서/보고서 자동 검색/성공 기준/**브랜치 적용 범위**
+ 출력 탭/보고서/보고서 수동 구성/*report-name-1*/성공 기준/**브랜치 적용 범위**
## Vulnerabilities
(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**Vulnerabilities**)
또는
(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**Vulnerabilities**)
(선택 사항)
SCA 보고서에서 허용되는 취약성의 최대 수와 심각도를 지정하여 관련 CodeCatalyst 보고서를 통과로 표시합니다. 취약성을 지정하려면 다음을 지정해야 합니다.
+ 개수에 포함하려는 취약성의 최소 심각도입니다. 최대부터 최소 심각도까지 유효한 값은 `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` 및 `INFORMATIONAL`입니다.
예를 들어 `HIGH` 선택 시 `HIGH` 및 `CRITICAL` 취약성이 집계됩니다.
+ 허용하려는 지정된 심각도의 최대 취약성 수입니다. 이 수를 초과하면 CodeCatalyst 보고서가 실패로 표시됩니다. 유효한 값은 정수입니다.
취약성 기준은 SCA 보고서에만 적용됩니다. SCA 보고서에 대한 자세한 내용은 [소프트웨어 구성 분석 보고서](test-workflow-actions.md#test-sca-reports)의 내용을 참조하세요.
최소 심각도를 지정하려면 `Severity` 속성을 사용합니다. 최대 취약성 수를 지정하려면 `Number` 속성을 사용합니다.
SCA 보고서에 대한 자세한 내용은 [품질 보고서 유형](test-workflow-actions.md#test-reporting)의 내용을 참조하세요.
해당 UI:
+ 출력 탭/보고서/보고서 자동 검색/성공 기준/**취약성**
+ 출력 탭/보고서/보고서 수동 구성/*report-name-1*/성공 기준/**취약성**
## Reports
(*action-name*/Outputs/**Reports** )
(선택 사항)
테스트 보고서의 구성을 지정하는 섹션입니다.
해당 UI: 출력 탭/**보고서**
## report-name-1
(*action-name*/Outputs/Reports/**report-name-1** )
([Reports](#github.configuration.reports) 포함 시 필수)
원시 보고서에서 생성될 CodeCatalyst 보고서에 부여할 이름입니다.
해당 UI: 출력 탭/보고서 수동 구성/**보고서 이름**
## Format
(*action-name*/Outputs/Reports/*report-name-1*/**Format**)
([Reports](#github.configuration.reports) 포함 시 필수)
보고서에 사용할 파일 형식을 지정합니다. 가능한 값은 다음과 같습니다.
+ 테스트 보고서의 경우:
+ Cucumber JSON에서 **Cucumber**(시각 편집기) 또는 `CUCUMBERJSON`(YAML 편집기)를 지정합니다.
+ JUnit XML에 **JUnit**(시각 편집기) 또는 `JUNITXML`(YAML 편집기)를 지정합니다.
+ NUnit XML에 **NUnit**(시각 편집기) 또는 `NUNITXML`(YAML 편집기)를 지정합니다.
+ NUnit 3 XML에서 **NUnit3**(시각 편집기) 또는 `NUNIT3XML`(YAML 편집기)를 지정합니다.
+ Visual Studio TRX에서 **Visual Studio TRX**(시각 편집기) 또는 `VISUALSTUDIOTRX`(YAML 편집기)를 지정합니다.
+ TestNG XML에서 **TestNG**(시각 편집기) 또는 `TESTNGXML`(YAML 편집기)를 지정합니다.
+ 코드 적용 범위 보고서의 경우:
+ Clover XML에서 **Clover**(시각 편집기) 또는 `CLOVERXML`(YAML 편집기)를 지정합니다.
+ Cobertura XML에서 **Cobertura**(시각 편집기) 또는 `COBERTURAXML`(YAML 편집기)를 지정합니다.
+ JaCoCo XML의 경우 **JaCoCo**(시각 편집기) 또는 `JACOCOXML`(YAML 편집기)를 지정합니다.
+ [simplecov-json](https://github.com/vicentllongo/simplecov-json)이 아닌 [simplecov](https://github.com/simplecov-ruby/simplecov)에서 생성한 SimpleCov JSON의 경우 **Simplecov**(시각 편집기) 또는 `SIMPLECOV`(YAML 편집기)를 지정합니다.
+ 소프트웨어 구성 분석(SCA) 보고서의 경우:
+ SARIF에서 **SARIF**(시각 편집기) 또는 `SARIFSCA`(YAML 편집기)를 지정합니다.
해당 UI: 출력 탭/보고서/보고서 수동 구성/보고서 추가/*report–name-1*/**보고서 유형** 및 **보고서 형식**
## Configuration
(*action-name*/**Configuration**)
(필수) 작업의 구성 속성을 정의할 수 있는 섹션입니다.
해당 UI: **구성** 탭
## Steps
(*action-name*/Configuration/**Steps**)
(필수)
[GitHub Marketplace](https://github.com/marketplace)의 작업 세부 정보 페이지에 표시되는 대로 GitHub 작업 코드를 지정합니다. 다음 지침에 따라 코드를 추가합니다.
1. GitHub 작업 `steps:` 섹션의 코드를 CodeCatalyst 워크플로의 `Steps:` 섹션에 붙여 넣습니다. 코드는 대시(-)로 시작하며 다음과 비슷합니다.
붙여넣을 GitHub 코드:
```
- name: Lint Code Base
uses: github/super-linter@v4
env:
VALIDATE_ALL_CODEBASE: false
DEFAULT_BRANCH: master
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
```
1. 방금 붙여넣은 코드를 검토하고 CodeCatalyst 표준을 준수하도록 필요에 따라 수정합니다. 예를 들어 앞의 코드 블록을 사용하면 *빨간색 기울임*꼴로 된 코드를 제거하고 **굵은** 글씨체로 된 코드를 추가할 수 있습니다.
CodeCatalyst 워크플로 yaml:
```
Steps:
- name: Lint Code Base
uses: github/super-linter@v4
env:
VALIDATE_ALL_CODEBASE: false
DEFAULT_BRANCH: mastermain
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
```
1. GitHub 작업에 포함되지만 `steps:` 섹션 내에 존재하지 않는 추가 코드는 CodeCatalyst에서 해당하는 코드를 사용하여 CodeCatalyst 워크플로에 추가합니다. [워크플로 YAML 정의](workflow-reference.md)를 검토하여 GitHub 코드를 CodeCatalyst에 이식하는 방법에 대한 인사이트를 얻을 수 있습니다. 자세한 마이그레이션 단계는 이 가이드의 범위를 벗어납니다.
다음은 **GitHub Actions** 작업에서 파일 경로를 지정하는 방법의 예입니다.
```
Steps:
- name: Lint Code Base
uses: github/super-linter@v4
...
- run: cd /sources/WorkflowSource/MyFolder/ && cat file.txt
- run: cd /artifacts/MyGitHubAction/MyArtifact/MyFolder/ && cat file2.txt
```
파일 경로 지정에 대한 자세한 내용은 [소스 리포지토리 파일 참조](workflows-sources-reference-files.md) 및 [아티팩트의 파일 참조](workflows-working-artifacts-refer-files.md)를 참조하세요.
해당 UI: 구성 탭/**GitHub Actions YAML**