리포지터리, 브랜치 및 CI 파이프라인

omnibus-gitlab CI 파이프라인은 프로젝트의 모든 미러 사이에 파이프라인이 분할되어있는 다소 복잡한 구조를 가지고 있습니다:

  1. 개발 리포지터리 - 일반 기능 개발용.
  2. 릴리스 미러 - 릴리스 아티팩트 빌드용.
  3. 보안 미러 - 보안 개발용.
  4. QA 미러 - 개발용 패키지 빌드 및 QA 실행용.

브랜치 및 태그 보호

보호된 브랜치

note
특별히 명시되지 않는 경우, 나열된 사용자/그룹은 보호된 브랜치에 대해 Merge 및 푸시 권한을 가지고 있습니다.
  1. 개발 리포지터리
    1. master: Maintainers, 배포 팀
    2. *-stable: 배포 팀, 릴리스 매니저
    3. *-stable-ee: 배포 팀, 릴리스 매니저
    4. *-auto-deploy-*: Maintainers, 배포 그룹, 매니저 그룹
  2. 릴리스 미러:
    1. master: Maintainers
    2. *-stable: Maintainers
    3. *-stable-ee: Maintainers
    4. *-auto-deploy-*: Maintainers
  3. 보안 미러:
    1. master: GitLab 릴리스 도구 봇, GitLab 봇, 배포 팀, 릴리스 매니저
    2. *-stable: GitLab 릴리스 도구 봇, GitLab 봇, 배포 팀, 릴리스 매니저
    3. *-stable-ee: GitLab 릴리스 도구 봇, GitLab 봇, 배포 팀, 릴리스 매니저
    4. *-auto-deploy-*: GitLab 릴리스 도구 봇, GitLab 봇, 배포 팀, 릴리스 매니저
  4. QA 미러:
    1. master: 개발자들 (Merge 전용), Maintainers
note
QA 미러의 개발자들은 해당 브랜치에서 트리거된 파이프라인을 실행하려면 master 브랜치에 액세스해야 합니다. 이 문제를 해결하기 위한 오픈 이슈가 있습니다.

보호된 태그

note
특별히 명시되지 않는 경우, 나열된 사용자/그룹은 보호된 태그에 대해 Merge 및 푸시 권한을 가지고 있습니다.
  1. 개발 리포지터리:
    1. *: Maintainers, 배포 팀, 릴리스 매니저
  2. 릴리스 미러:
    1. *: Maintainers

  3. 보안 미러: 없음

  4. QA 미러: 없음

리포지터리 간 미러링

대부분의 개발은 개발 리포지터리에서 이루어지며, 보안 관련 변경 사항은 보안 미러로 전달됩니다. 그런 다음 이러한 변경 사항은 릴리스 미러 및 QA 미러로 미러링됩니다. 다음 다이어그램은 각 리포지터리간에 미러링되는 항목을 설명합니다.

graph TD A[개발 리포지터리] -->|보호된 브랜치| B[보안 미러] A[개발 리포지터리] -->|보호된 브랜치| C[릴리스 미러] A[개발 리포지터리] -->|모든 브랜치| D[QA 미러] B[보안 미러] -->|보호된 브랜치| C[릴리스 미러] B[보안 미러] -->|모든 브랜치| D[QA 미러]

파이프라인 유형

omnibus-gitlab의 작업은 여러 미러에 걸쳐 분산되어 있기 때문에, 작업을 실행할 위치/시점을 지정하기 위해 rules 키워드를 사용하는 CI 구성이 비교적 복잡해집니다. 따라서 omnibus-gitlab은 각 필요한 파이프라인 유형을 PIPELINE_TYPE이라는 특정 변수로 표시하고 필요한 경우 다양한 파이프라인 유형에 작업을 추가하는 다른 방법을 사용합니다. 다양한 파이프라인 유형은 다음 표에 설명되어 있습니다:

파이프라인 유형 파이프라인 실행 미러 비고
DEPENDENCY_SCANNING_PIPELINE Canonical 의존성의 보안 취약점을 확인합니다. DEPENDENCY_SCANNING 변수가 true로 설정되어 있어야 합니다.
DEPS_IO_VERSION_BUMP_PIPELINE Canonical deps.io에서 브랜치 푸시에 따라 실행됩니다. 브랜치에 deps- 접두사가 있어야 합니다.
DEPS_IO_VERSION_CHECK_PIPELINE Canonical 업데이트를 검색하기 위해 deps를 실행합니다. DEPS_PIPELINE 변수가 true로 설정되어 있어야 합니다.
LICENSE_PAGE_UPDATE_PIPELINE Canonical 라이선스 페이지를 업데이트합니다. PAGES_UPDATE 변수가 true로 설정되어 있어야 합니다.
CACHE_UPDATE_PIPELINE Canonical, QA gem 캐시 및 패키지 빌드 캐시를 업데이트합니다. CACHE_UPDATE 변수가 true로 설정되어 있어야 합니다.
DURATION_PLOTTER_PIPELINE QA 빌드 지속 시간을 플롯하는 패키지 빌드를 실행합니다. DURATION_PLOTTER 변수가 true로 설정되어 있어야 합니다.
DOCS_PIPELINE Canonical, Security 브랜치 이름에 docs-를 접두사 또는 -docs를 접미사로 가져야 합니다.
PROTECTED_TEST_PIPELINE Canonical, Security 보호된 브랜치 및 태그에서 실행됩니다. 트리거 작업 및 danger-review와 같은 원하지 않는 작업은 포함되지 않습니다.
GITLAB_BRANCH_TEST_PIPELINE Canonical, Security 보호되지 않은 브랜치 푸시에서 실행됩니다. danger-review와 같은 원하지 않는 작업은 포함되지 않습니다. 트리거 작업이 포함됩니다.
GITLAB_MR_PIPELINE Canonical, Security Canonical/Security의 MR(예: GitLab 및 팀 멤버의 MR)에서 실행됩니다. 트리거 작업이 포함됩니다.
AUTO_DEPLOY_BUILD_PIPELINE 릴리스 자동 배포 태그가 푸시될 때 실행됩니다.
CE_BRANCH_BUILD_PIPELINE 릴리스 정기적인 브랜치 푸시 시 실행됩니다.
CE_NIGHTLY_BUILD_PIPELINE 릴리스 매일 밤 CE 빌드를 실행합니다.
CE_RC_BUILD_PIPELINE 릴리스 CE RC 태그가 푸시될 때 실행됩니다.
CE_TAG_BUILD_PIPELINE 릴리스 안정적인 CE 태그가 푸시될 때 실행됩니다.
EE_BRANCH_BUILD_PIPELINE 릴리스 일반 브랜치가 푸시될 때 빌드하되, EE 파이프라인 여부가 강제로 지정됩니다.
EE_NIGHTLY_BUILD_PIPELINE 릴리스 매일 밤 EE 빌드를 실행합니다. EE 파이프라인이 강제로 지정되어야 합니다.
EE_RC_BUILD_PIPELINE 릴리스 EE RC 태그가 푸시될 때 실행됩니다.
EE_TAG_BUILD_PIPELINE 릴리스 안정적인 EE 태그가 푸시될 때 실행됩니다.
TRIGGER_CACHE_UPDATE_PIPELINE QA 트리거된 QA 파이프라인의 빌드 캐시를 업데이트합니다. CACHE_UPDATE 변수가 true로 설정되어 있어야 합니다.
TRIGGERED_CE_PIPELINE QA 트리거된 e2e:package-and-test 빌드로 CE 패키지 및 이미지를 실행합니다.
TRIGGERED_EE_PIPELINE QA 트리거된 e2e:package-and-test 빌드로 EE 패키지 및 이미지를 실행합니다.
FORK_BRANCH_TEST_PIPELINE 포크 프로젝트의 포크에서 실행하는 테스트 스위트입니다. 트리거 작업 및 danger-review와 같은 원하지 않는 작업은 포함되지 않습니다.
FORK_MR_PIPELINE 포크 프로젝트의 포크에서 발신된 MR입니다. 트리거 작업은 포함되지 않습니다.

브랜치 파이프라인

omnibus-gitlab는 아직 분리된 Merge Request 파이프라인을 사용하지 않습니다. 따라서 브랜치 푸시에 의한 파이프라인은 이 프로젝트에서 일반적으로 만나는 파이프라인입니다. 이러한 파이프라인은 개발 리포지터리, 보안 미러, 및 릴리스 미러에서 사용됩니다.

태그 파이프라인

릴리스 미러로의 태그 푸시는 릴리스 작업을 사용하여 파이프라인을 시작합니다. 개발 리포지터리 및 보안 미러로의 태그 푸시는 일반적인 브랜치 푸시와 같이 작동합니다(단, e2e:package-and-test 파이프라인을 시작할 옵션이 없음) 및 기본적인 스타일 체크 및 단위 테스트를 실행합니다.

예약된 파이프라인

개발 리포지터리에서는 두 개의 예약된 파이프라인이 있습니다.

  1. 의존성 업데이트 - dependency_update 작업을 사용하여 오래된 의존성을 확인하는 파이프라인
  2. 라이선스 페이지 생성 - S3 버킷에서 라이선스 정보를 사용하여 라이선스 수집 웹페이지를 채우는 파이프라인

릴리스 미러에서는 두 개의 예약된 파이프라인이 있습니다

  1. CE nightly - GitLab CE를 위한 밤간 패키지 및 Docker 이미지를 빌드하는 파이프라인
  2. EE nightly - GitLab EE를 위한 밤간 패키지 및 Docker 이미지를 빌드하는 파이프라인

다른 미러에는 예약된 파이프라인이 없습니다

자동 배포 파이프라인

GitLab은 릴리스 프로세스를 위해 자동 배포 브랜치 및 태그를 사용합니다. 이러한 브랜치는 <주요>-<마이너>-auto-deploy-<타임스탬프>라는 이름을 가지며 태그는 <주요>.<마이너>.<타임스탬프>+<gitlab sha>.<omnibus-gitlab sha> 형식을 가집니다.

GitLab 환경에 변경 사항을 배포하는 데 필요한 일부 작업만이 이 파이프라인의 일부가 될 것입니다.

트리거된 파이프라인

QA 미러에서 “e2e:package-and-test” 파이프라인을 실행하기 위해 트리거된 파이프라인을 사용합니다. 이것은 개발 리포지터리 또는 GitLab 프로젝트의 파이프라인에서 트리거할 수 있습니다.

본 파이프라인은 개발자들에게 변경 사항을 테스트하기 위한 패키지와 이미지를 제공하고 이러한 artifact에 대한 자동 QA 실행을 추가로 제공합니다. 또한, 이러한 artifact를 사용하여 생성된 HA 인스턴스에 대한 QA 실행을 선택적으로 수행할 수 있는 옵션이 제공됩니다.

CI 작업

개발 작업

danger-review

이 작업은 Danger 도구를 사용하여 Merge Request에 대한 일부 기본 요구 사항을 충족시키는지를 확인합니다.

이 작업은 브랜치 및 태그 파이프라인에서만 개발 리포지터리 및 보안 미러에서 실행됩니다.

rubocop

소스 코드 파일을 확인하여 특정한 스타일 요구 사항을 충족하는지 확인합니다.

이 작업은 브랜치 및 태그 파이프라인에서만 개발 리포지터리 및 보안 미러에서 실행됩니다.

docs-lint

문서 파일을 확인하여 특정한 스타일 요구 사항을 충족하는지 확인합니다.

이 작업은 브랜치 및 태그 파이프라인에서만 개발 리포지터리 및 보안 미러에서 실행됩니다.

review-docs-deploy

현재 커밋에서 GitLab Docs에 대한 리뷰 앱을 배포할 gitlab-docs에서 문서 빌드를 트리거하는 매뉴얼 작업.

이 작업은 브랜치 파이프라인에서만 개발 리포지터리에서 실행됩니다.

review-docs-cleanup

review-docs-deploy에 의해 생성된 환경을 중지하는 매뉴얼 작업. Merge Request을 Merge하는 것에 따라 자동으로 실행됩니다.

이 작업은 브랜치 파이프라인에서만 개발 리포지터리에서 실행됩니다.

<OS_NAME> knapsack

RSpec 및 Chefspec를 사용하여 Chef 레시피 및 라이브러리를 테스트하는 작업. knapsack의 도움으로 병렬화됩니다.

이 작업은 브랜치 및 태그 파이프라인에서만 개발 리포지터리 및 보안 미러에서 실행됩니다.

<OS_NAME> specs

parallel 키워드를 사용하여 6개로 병렬화된 rspec를 실제로 실행하는 작업

이 작업은 브랜치 및 태그 파이프라인에서만 개발 리포지터리 및 보안 미러에서 실행됩니다.

update-knapsack

단위 테스트의 각 병렬 실행에서 보고서를 결합하고 최종 JSON 보고서를 준비하는 작업. 이 보고서는 MR 위젯에서 spec 상태를 표시하는 데 사용되며 다음 파이프라인 실행을 위해 캐시로 업로드됩니다.

이 작업은 브랜치 및 태그 파이프라인에서만 개발 리포지터리 및 보안 미러에서 실행됩니다.

Trigger:ce-package

이 작업은 QA 미러에서 패키지 빌드와 개발 목적을 위한 QA를 실행하기 위해 파이프라인을 트리거하는 매뉴얼 작업입니다. 개발자들은 테스트를 위해 패키지 또는 Docker 이미지를 가져오거나 MR의 변경에 대해 전체 QA 스위트를 실행하는 데 사용할 수 있습니다.

QA 실패를 디버그하려면 QA 실패 조사 섹션을 참조하십시오. 이 작업은 또한 Allure 보고서를 생성하며 자세한 내용 및 데모는 Omnibus-GitLab에서 테스트 보고서 생성에서 확인할 수 있습니다.

이 작업은 브랜치 파이프라인에서만 개발 리포지터리 및 보안 미러에서 실행됩니다.

Trigger:ee-package

Trigger:ce-package와 동일하지만 EE 패키지를 빌드합니다.

이 작업은 브랜치 파이프라인에서만 개발 리포지터리 및 보안 미러에서 실행됩니다.

fetch-assets

패키지를 빌드하기 위해 GitLab 또는 GitLab-FOSS 파이프라인에서 이미 컴파일된 Rails 에셋을 사용합니다. 이 파이프라인들은 Docker 이미지로 푸시하며, 여기서는 해당 이미지를 가져와 에셋 자체를 미리 정의된 위치로 복사합니다.

이 작업은 브랜치, 태그 및 트리거된 파이프라인에서만 릴리스 미러 및 QA 미러에서 실행됩니다.

Trigger:package

이 작업은 하나의 패키지를 빌드하여 아티팩트로 제공합니다.

이 작업은 트리거된 파이프라인에서만 QA 미러에서 실행됩니다.

Trigger:gitlab-docker

이 작업은 Trigger:package 작업에서 빌드된 패키지를 사용하여 GitLab Docker 이미지를 빌드합니다.

이 작업은 트리거된 파이프라인에서만 QA 미러에서 실행됩니다.

qa-subset-test

이 작업은 테스트 스위트의 부분을 실행하며 Trigger:CE-package 또는 Trigger:EE-package 매뉴얼 작업이 수동으로 트리거될 때 자동으로 실행됩니다.

이 작업은 GitLab QA Mirror에서 파이프라인을 트리거하여 Trigger:gitlab-docker 작업에서 생성된 GitLab Docker 이미지와 GitLab Rails 파이프라인에서 빌드된 GitLab QA Docker 이미지를 전달하여 이 이슈에서 언급된 대로 이 이미지를 사용하여 일부 테스트를 실행합니다.

이 작업은 트리거된 파이프라인에서만 QA 미러에서 실행됩니다.

qa-remaining-test-manual

이 작업은 qa-subset-test 작업에서 실행되지 않는 나머지 테스트를 실행하는 매뉴얼 트리거 작업입니다.

MR 파이프라인에서 이 QA 작업을 실행하려면 Trigger:CE-package 또는 Trigger:EE-package 매뉴얼 작업을 트리거해야 합니다.

이 작업은 GitLab QA Mirror에서 파이프라인을 트리거하여 Trigger:gitlab-docker 작업에서 생성된 GitLab Docker 이미지와 GitLab Rails 파이프라인에서 생성된 GitLab QA Docker 이미지를 전달하여 전체 테스트 스위트를 실행합니다.

RAT

이 매뉴얼 작업은 RAT 프로젝트에서 Trigger:package 작업에서 빌드된 패키지의 URL을 전달하여 해당 패키지를 사용하여 GET을 이용해 PostgreSQL HA 인스턴스를 실행하고 해당 인스턴스에서 QA를 실행합니다.

이 작업은 트리거된 EE 파이프라인에서만 QA 미러에서 실행됩니다.

<OS_NAME>-branch

이 작업은 지정된 OS용 패키지를 빌드하고, 해당 결과 패키지를 S3 버킷에 푸시하여 아티팩트로 제공합니다.

이 작업은 브랜치 및 매일 파이프라인에서만 릴리스 미러에서 실행됩니다.

참고: Raspberry Pi 작업은 CE 브랜치에서만 실행되며, SLES 작업은 EE 브랜치에서만 실행됩니다.

Docker-branch

이 작업은 Ubuntu 22.04-branch 작업 중에 빌드된 패키지를 사용하여 GitLab Docker 이미지를 빌드합니다. 해당 이미지는 GitLab 컨테이너 레지스트리에 푸시됩니다.

이 작업은 브랜치 및 매일 파이프라인에서만 릴리스 미러에서 실행됩니다.

QA-branch

이 작업은 Rails 코드베이스의 qa 디렉터리에서 GitLab QA Docker 이미지를 빌드합니다.

이 작업은 브랜치 및 매일 파이프라인에서만 릴리스 미러에서 실행됩니다.

릴리스 작업

<OS_NAME>

이 작업은 지정된 OS용 패키지를 빌드하고, 해당 결과 패키지를 S3 버킷에 푸시하여 아티팩트로 제공합니다.

이 작업은 태그 파이프라인에서만 릴리스 미러에서 실행됩니다.

참고: Raspberry Pi 작업은 CE 태그에서만 실행되며, SLES 작업은 EE 태그에서만 실행됩니다.

<OS_NAME>-staging

이 작업은 이전 작업에서 빌드된 패키지를 Packagecloud 인스턴스의 내부 스테이징 리포지터리에 업로드합니다.

이 작업은 태그 파이프라인에서만 릴리스 미러에서 실행됩니다.

참고: Raspberry Pi 작업은 CE 태그에서만 실행되며, SLES 작업은 EE 태그에서만 실행됩니다.

<OS_NAME>-release

이 작업은 내부 스테이징 리포지터리에서 패키지를 공개 리포지터리로 가져옵니다.

이 작업은 태그 파이프라인에서만 릴리스 미러에서 실행됩니다.

참고: Raspberry Pi 작업은 CE 태그에서만 실행되며, SLES 작업은 EE 태그에서만 실행됩니다.

Docker

이 작업은 Ubuntu 22.04-branch 작업 중에 빌드된 패키지를 사용하여 GitLab Docker 이미지를 빌드합니다. 해당 이미지는 내부 GitLab 컨테이너 레지스트리에 푸시됩니다.

이 작업은 태그 파이프라인에서만 릴리스 미러에서 실행됩니다.

Docker-Release

이 작업은 내부 GitLab 컨테이너 레지스트리에서 GitLab Docker 이미지를 가져와 Dockerhub에 푸시합니다.

이 작업은 태그 파이프라인에서만 릴리스 미러에서 실행됩니다.

Docker-QA

이 작업은 Rails 코드베이스의 qa 디렉터리에서 GitLab QA Docker 이미지를 빌드하고 내부 GitLab 컨테이너 레지스트리에 푸시합니다.

이 작업은 릴리스 미러 및 태그 파이프라인에서만 실행됩니다.

QA-Tag

이 작업은 내부 GitLab 컨테이너 레지스트리에서 GitLab QA Docker 이미지를 가져와 Dockerhub에 푸시합니다.

이 작업은 릴리스 미러 및 태그 파이프라인에서만 실행됩니다.

AWS

이 작업은 Ubuntu 20.04 패키지를 사용하여 라이선스가 없는 AWS AMI를 빌드합니다.

이 작업은 릴리스 미러 및 태그 파이프라인에서만 실행됩니다.

AWS-Ultimate

이 작업은 Ubuntu 20.04 패키지를 사용하여 내장 Ultimate 라이선스가 포함된 AWS AMI를 빌드합니다.

이 작업은 릴리스 미러 및 EE 태그 파이프라인에서만 실행됩니다.

AWS-Premium

이 작업은 Ubuntu 20.04 패키지를 사용하여 내장 Premium 라이선스가 포함된 AWS AMI를 빌드합니다.

이 작업은 릴리스 미러 및 EE 태그 파이프라인에서만 실행됩니다.

AWS-CE-Release

이 작업은 현재 버전으로 AWS Marketplace의 GitLab Community Edition 디렉터리을 업데이트합니다.

이 작업은 릴리스 미러 및 CE 태그 파이프라인에서만 실행됩니다.

AWS-Ultimate-Release

이 작업은 현재 버전으로 AWS Marketplace의 GitLab Ultimate 디렉터리을 업데이트합니다.

이 작업은 릴리스 미러 및 EE 태그 파이프라인에서만 실행됩니다.

AWS-Premium-Release

이 작업은 현재 버전으로 AWS Marketplace의 GitLab Premium 디렉터리을 업데이트합니다.

이 작업은 릴리스 미러 및 EE 태그 파이프라인에서만 실행됩니다.

create_omnibus_manifest

이 작업은 dependency_scanning 작업에서 사용되는 version-manifest.json 파일을 생성합니다.

이 작업은 릴리스 미러 및 태그 및 nightly 파이프라인에서만 실행됩니다.

dependency_scanning

이 작업은 패키지의 모든 컴포넌트에 대해 의존성 스캔을 실행하여 알려진 취약점이 있는지 확인합니다.

이 작업은 릴리스 미러 및 태그 및 nightly 파이프라인에서만 실행됩니다.

RAT-Nightly

이 작업은 이 파이프라인에서 빌드된 nightly Ubuntu 22.04 패키지의 URL을 전달하여 RAT 프로젝트에서 파이프라인을 트리거하고, 해당 패키지를 사용하여 GET을 통해 PostgreSQL HA 인스턴스를 실행하고 그 인스턴스에서 QA를 실행합니다.

이 작업은 릴리스 미러에서만 nightly 파이프라인에서 실행됩니다.

RAT-Tag

이 작업은 이 파이프라인에서 빌드된 Ubuntu 22.04 패키지의 URL을 전달하여 RAT 프로젝트에서 파이프라인을 트리거하고, 해당 패키지를 사용하여 GET을 통해 PostgreSQL HA 인스턴스를 실행하고 그 인스턴스에서 QA를 실행합니다.

이 작업은 릴리스 미러에서만 EE 태그 파이프라인에서 실행됩니다.

license-upload

이 작업은 패키지의 모든 의존성의 라이선스 정보를 컴파일하고 S3 버킷에 업로드합니다. 이는 pages 예약된 작업에서 사용되어 Development repository의 License collection webpage를 작성하는 데 사용됩니다.

관리 작업

update-gems-cache 및 update-trigger-package-cache

이 작업은 각각 .gems-cache 및 .trigger-package-cache 공유 cache 정의를 확장하는 작업으로, 캐시를 가져오기만 합니다.

이 캐시는 update-gems-cache 및 update-trigger-package-cache 작업에서 각각 CACHE_UPDATE가 존재할 때 예약된 파이프라인에서 업데이트됩니다.

dependency_update

이 작업은 Dependencies.io를 사용하여 패키지에 포함된 다양한 컴포넌트의 버전 업데이트를 자동으로 확인하고, 업데이트가 발견되면 Development repository에 대한 Merge Request을 엽니다.

이 작업은 Development repository에서만, DEPS_PIPELINE 변수가 존재할 때 예약된 파이프라인에서 실행됩니다.

dependencies_io_check

이 작업은 dependency_update 작업에 의해 Merge Request이 만들어진 경우, QA mirror에서 e2e:package-and-test 파이프라인을 자동으로 트리거합니다 (Trigger:ce-package 작업과 유사함) .

이 작업은 Development repository에서만 브랜치 이름이 deps로 시작할 때 (dependency_update 작업이 Merge Request에 사용하는 형식) 실행됩니다.

valdiate_packer_changes

이 작업은 packer configuration files이 유효한지 확인합니다.

이 작업은 Development repository 및 Security mirror에서만, packer configuration files 중 하나가 수정될 때 실행됩니다.

pages

이 작업은 GitLab Pages와 연결되어, 패키지에 포함된 여러 컴포넌트의 라이선스 정보를 포함하는 정적 웹 사이트를 생성합니다. GitLab의 각 릴리스에 대해 생성됩니다.

이 작업은 Development repository에서만 DEPS_PIPELINE 변수가 없는 예약된 파이프라인에서 (예약된 파이프라인이 dependency_update 실행과 구분되도록) 실행됩니다.