Files

T

DongHyeonka d71669eb59 fix: 하네스 제거 및 keycloak 문서 보강

2026-07-25 12:53:13 +09:00

10 KiB

Raw Permalink Blame History

title, source_type, url, archive_url, status, confidence, tags, related_projects, related_branches, created, last_reviewed

title

source_type

url

archive_url

status

confidence

CI 비교 — GitHub Actions vs GitLab CI/CD (그리고 Jenkins / CircleCI / Tekton)

Layer: raw/official-docs/ — 공식 문서 발췌. CI provider 별 동일 개념(jobs/stages/needs)의 매핑 baseline.

Parent / 활용 branch (필수)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-ci-quality-gates-contract	Gate ↔ Branch Contract Test 소유권 매트릭스의 backend 를 GitHub Actions 로 고정한 근거 (다른 provider 의 동일 개념 매핑)
raw/branch-notes/feature-build-release-supply-chain-contract	SBOM / Cosign / SLSA gate 가 어떤 provider step 으로 표현되는지의 이식성 baseline

특정 branch 없이 foundational 조사로 수집한 경우:

raw/project-notes/ca-skeleton-operational-contract — ca-tmpl 의 CI backend 의사결정의 외부 비교 기준

컨텍스트 / 왜 저장했는지

feature-ci-quality-gates-contract 가 release-blocking gate 매트릭스를 정의하는데, gate 구현 backend 를 GitHub Actions 로 고정한 근거가 필요합니다. matrix job, required check, workflow status 의존성 (needs:, if: success()) 은 provider 별로 모델이 다르므로, 다른 provider 에서의 동일 개념을 raw 로 확보해 두면 향후 이식 시 비용을 추정할 수 있습니다.

출처 / Source

원본 URL:
- GitHub Actions migration guide — https://docs.github.com/en/actions/learn-github-actions/migrating-from-gitlab-cicd-to-github-actions
- GitLab CI/CD pipelines — https://docs.gitlab.com/ee/ci/pipelines/
- Jenkins Declarative Pipeline — https://www.jenkins.io/doc/book/pipeline/syntax/
- CircleCI configuration reference — https://circleci.com/docs/configuration-reference/
- Tekton Pipelines overview — https://tekton.dev/docs/pipelines/
아카이브 URL: (미수집)
저자 / 조직: GitHub Docs, GitLab Docs, Jenkins Project, CircleCI, CD Foundation (Tekton)
발행일: 공식 문서 (지속 갱신, fetched 2026-05-27)
마지막 확인일: 2026-05-27

핵심 인용 / Key quotes (verbatim)

[GitHub Docs §Introduction — Migrating from GitLab CI/CD] "GitLab CI/CD and GitHub Actions both allow you to create workflows that automatically build, test, publish, release, and deploy code."

[GitHub Docs §Jobs — needs key] "GitLab CI/CD also has a concept of stages, where jobs in a stage run concurrently, but the next stage will start when all the jobs in the previous stage have completed. You can recreate this scenario in GitHub Actions with the needs key."

[GitHub Docs §Jobs — needs key] "Job dependencies in GitHub Actions can be specified explicitly with the needs key."

[GitHub Docs §Scripts] "In GitLab CI/CD, script steps are specified using the script key. In GitHub Actions, all scripts are specified using the run key."

[Jenkins Handbook §Pipeline syntax] "Declarative Pipeline … presents a more simplified and opinionated syntax on top of the Pipeline sub-systems. … The agent directive tells Jenkins where and how to execute the Pipeline, and is required in a declarative pipeline."

[Tekton §Pipelines overview] "A Pipeline is a collection of Tasks that you define and arrange in a specific order of execution as part of your continuous integration flow. Each Task … runs as a Pod on your Kubernetes cluster."

Claims Extracted / 추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
CIGG-C1	GitHub Actions 와 GitLab CI/CD 는 모두 build/test/publish/release/deploy 를 자동화하는 workflow 작성을 지원한다	[GitHub Docs §Introduction — Migrating from GitLab CI/CD] "GitLab CI/CD and GitHub Actions both allow you to create workflows that automatically build, test, publish, release, and deploy code."	`official-vendor-doc`	두 provider 의 일반 워크플로우 능력 비교	두 provider 의 marketplace / extension 생태계가 동등하다는 뜻은 아님 — capability 만 동등
CIGG-C2	GitLab 의 `stages` (같은 stage 의 job 은 concurrent, 다음 stage 는 이전 stage 완료 후 시작) 는 GitHub Actions 의 `needs` key 로 재현 가능	[GitHub Docs §Jobs — needs key] "GitLab CI/CD also has a concept of `stages`, where jobs in a stage run concurrently, but the next stage will start when all the jobs in the previous stage have completed. You can recreate this scenario in GitHub Actions with the `needs` key."	`official-vendor-doc`	GitHub Actions ↔ GitLab CI/CD stage 모델 이식	`needs` 가 GitLab `stages` 의 모든 의미를 1:1 로 보존한다는 뜻은 아님 — `interruptible:` / `manual` 등 GitLab-specific keyword 는 별도 매핑 필요
CIGG-C3	GitHub Actions 의 job dependency 는 `needs` key 로 명시한다	[GitHub Docs §Jobs — needs key] "Job dependencies in GitHub Actions can be specified explicitly with the `needs` key."	`official-vendor-doc`	GitHub Actions YAML 작성	`needs` 의 fan-in/fan-out 시 status 전파 규칙 (e.g., `if: always()`) 의 정확한 의미는 본 인용에 명시 없음
CIGG-C4	GitLab CI/CD 의 `script` key 는 GitHub Actions 에서 `run` key 로 매핑된다	[GitHub Docs §Scripts] "In GitLab CI/CD, script steps are specified using the `script` key. In GitHub Actions, all scripts are specified using the `run` key."	`official-vendor-doc`	shell script 의존 step 의 단순 이식	`before_script` / `after_script` (GitLab) 의 GitHub 대응 (pre/post composite action, setup steps) 은 본 인용 범위 밖
CIGG-C5	Jenkins Declarative Pipeline 은 Pipeline sub-system 위의 단순화된 syntax 이며 `agent` directive 가 필수 (실행 위치/방법 지정)	[Jenkins Handbook §Pipeline syntax] "Declarative Pipeline … presents a more simplified and opinionated syntax on top of the Pipeline sub-systems. … The `agent` directive tells Jenkins where and how to execute the Pipeline, and is required in a declarative pipeline."	`official-vendor-doc`	Jenkins Declarative Pipeline 작성	Scripted Pipeline (`node('label') { ... }`) 의 차이 / plugin 호환성은 본 인용 범위 밖
CIGG-C6	Tekton 의 `Pipeline` 은 `Task` 들의 collection 이며, 각 `Task` 는 Kubernetes cluster 의 Pod 로 실행된다	[Tekton §Pipelines overview] "A `Pipeline` is a collection of `Tasks` that you define and arrange in a specific order of execution as part of your continuous integration flow. Each `Task` … runs as a Pod on your Kubernetes cluster."	`official-vendor-doc`	Tekton CI/CD 운영 모델 (k8s-native)	self-hosted Kubernetes 비용 모델이 GitHub Actions runner 와 동등하다는 뜻은 아님 — infra 비용은 별도

Usage Boundaries / 적용 경계

이 자료가 직접 증명하는 것:
- CIGG-C1: 두 major provider 가 동일 워크플로우 카테고리 (build/test/publish/release/deploy) 를 지원한다는 사실
- CIGG-C2, CIGG-C3: stages ↔ needs 매핑이 GitHub 공식 문서에 명시되어 있다는 사실
- CIGG-C4: script ↔ run 의 명시적 매핑
- CIGG-C5: Jenkins Declarative Pipeline 의 agent 필수 요건
- CIGG-C6: Tekton 의 k8s-Pod 기반 실행 모델
이 자료가 증명하지 않는 것:
- 각 provider 의 비용 / SLA / 가용성 비교
- 어떤 provider 가 ca-tmpl 에 best fit 인가 — 이 결정은 별도 ADR 필요
- matrix job 의 정확한 표현 차이 (strategy.matrix vs parallel: matrix: vs axes)
- reproducible build 보장 수준 (Nix / Bazel / cosign 등 별도 도구)
- 어떤 provider 가 SLSA Level 3+ certification 을 가진가 (별도 SLSA 문서 확인)
내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- ca-tmpl 의 quality-gate workflow 가 needs: [contract-test, openapi-check, sbom-attest] 형태로 표현되는지의 실제 yaml 검증
- 향후 GitLab 이식 시 interruptible: / rules:if: / parallel:matrix: 의 GitHub Actions equivalence 매핑 완성도
- Tekton 이식의 infra 비용 (self-hosted k8s cluster 운영) 추정

메모 / Notes (내 프로젝트 해석)

본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.

GitHub Actions: needs: + if: success() 조합으로 contract test gate ↔ release-blocking 매트릭스를 단일 yaml 에서 강제 가능. branch note 의 "workflow yaml 의 needs: [contract-test] 의존성" 가설과 일치.
GitLab CI: rules: + needs: + interruptible: 조합이 GitHub 의 if: + needs: + concurrency: 에 매핑. matrix 는 parallel: matrix: 키워드.
Jenkins: declarative pipeline 의 post { failure { ... } } 는 GitHub 의 if: failure() step 에 해당. 단, plugin 의존도가 높아 reproducible build 와 충돌 위험.
Tekton: k8s-native 라 self-hosted runner 비용 모델이 다름. ca-skeleton 단계에는 과한 인프라.
CircleCI / Buildkite / Drone: 상용/소형 팀 옵션. ca-tmpl 의 default 를 GitHub Actions 로 잡되, gate 정의는 provider-agnostic 하게 작성해야 이식 가능.

같은 주제 다른 official-doc:
- raw/official-docs/ci-openapi-snapshot-diff-tooling — OpenAPI drift gate 도구 체인
적용 branch-note:
- raw/branch-notes/feature-ci-quality-gates-contract — Gate ↔ Branch Contract Test 소유권 매트릭스의 backend 선택 근거
- raw/branch-notes/feature-build-release-supply-chain-contract — SBOM / Cosign / SLSA gate 가 어떤 provider step 으로 표현되는지

10 KiB Raw Permalink Blame History