Fedora 45 릴리스 프로세스 및 빌드 파이프라인

Fedora 45는 소스 제어, 클린룸 빌드, 게이티드 업데이트(gated updates), 그리고 다단계 컴포지션 프로세스를 포함하는 고도로 자동화된 파이프라인을 통해 소스 코드를 설치 가능한 아티팩트로 변환합니다. 이 시스템은 모든 ISO, 클라우드 이미지 및 컨테이너 이미지가 최종 사용자에게 도달하기 전에 재현 가능하고, 감사 가능하며, 테스트되었음을 보장합니다.

소스 제어 및 패키지 정의

Fedora는 src.fedoraproject.org에서 호스팅되는 개별 Git 저장소에서 패키지 정의를 관리합니다 (Pagure에서 Forgejo로 마이그레이션 중). 각 저장소에는 RPM spec 파일, 다운스트림 패치, 그리고 바이너리 파일이 Git에 포함되지 않도록 lookaside cache의 upstream tarball을 가리키는 sources 파일이 포함되어 있습니다.

패키저(Packager)는 주로 fedpkg CLI를 사용하여 이러한 저장소를 관리합니다. 패키저가 fedpkg build를 실행하면, 도구는 특정 Git 커밋을 가리키는 URL을 생성하고 이를 Koji에 제출하여, 해당 커밋 해시로부터 빌드가 완전히 재현 가능하도록 보장합니다.

빌드 시스템: Koji

Koji는 Fedora의 중앙 빌드 시스템 역할을 합니다. Koji는 수동적인 XML-RPC 서버가 PostgreSQL 데이터베이스를 관리하고, 빌더 데몬이 작업을 위해 이 허브를 폴링하는 hub-and-spoke 아키텍처를 채택하고 있습니다.

재현 가능성을 보장하기 위해, Koji는 모든 빌드에 대해 새로운 Mock chroot 환경을 생성하여 이전 빌드로부터의 "누출(leakage)"을 방지합니다. 시스템은 빌드 태그(tags)—이름이 지정된 빌드 컬렉션—를 사용하여 빌드를 조직합니다. 빌드 타겟은 요청을 빌드 태그(buildroot 정의)와 대상 태그(완료된 RPM이 저장되는 위치)에 매핑합니다. Koji는 또한 Kiwi 이미지, Image Builder 및 OSTree 컴포즈를 위한 플러그인을 통해 비-RPM 아티팩트를 오케스트레이션합니다.

업데이트 게이팅: Bodhi

브랜치 릴리스의 경우, RPM이 Koji에서 사용자에게 직접 이동하지 않습니다. 대신, 업데이트 관리 시스템인 Bodhi에 의해 게이팅됩니다. Bodhi는 업데이트의 전환을 pending, testing, stable의 세 가지 상태로 관리합니다.

업데이트는 "karma"(사용자 및 자동 테스트 피드백)와 테스트에 소요된 시간에 따라 안정성을 향해 이동합니다. 부팅 및 기본 기능에 필수적인 크리티컬 패스(Critical path) 패키지는 더 긴 테스트 기간(7일 대신 14일)과 더 높은 karma 임계값을 포함하여 더 엄격한 요구 사항을 적용받습니다. Bodhi는 CI 게이팅을 위해 Greenwave 및 ResultsDB와 통합되며, 업데이트가 stable로 표시되면 Bodhi는 Pungi를 호출하여 실제 DNF 저장소를 컴포지션합니다.

릴리스 컴포지션: Pungi

Pungi는 개별 RPM을 ISO 및 클라우드 이미지와 같은 최종 제품으로 변환하기 위해 다양한 도구를 조정하는 오케스트레이터입니다. 프로세스는 일관성을 유지하기 위해 엄격한 순서를 따릅니다:

1. 패키지 세트 동결 (Pkgset)

Pungi는 먼저 특정 Koji 태그의 스냅샷을 찍습니다. 이 Pkgset 단계는 모든 후속 단계에서 동결된 패키지 세트를 사용하도록 보장하여, 전체 컴포지션을 감사 가능하게 만들고 진행 중인 릴리스에 새로운 Koji 빌드가 몰래 포함되는 것을 방지합니다.

2. 제품 정의 (Comps 및 Variants)

Pungi는 제품 구성을 결정하기 위해 두 개의 XML 입력을 사용합니다:

• Comps (fedora-comps): 패키지 그룹(예: gnome-desktop)과 각 패키지의 역할(필수, 기본, 선택 사항 또는 조건부)을 정의합니다.
• Variants XML: 특정 제품(예: Workstation, Server, Silverblue)과 해당 제품이 포함하는 comps 그룹을 정의합니다.

3. 부트 이미지 및 ISO 제작

• Buildinstall: lorax를 사용하여 Anaconda 설치 프로그램을 부팅하는 최소 이미지인 boot.iso를 생성합니다. 이것은 모든 설치용 ISO의 기반이 됩니다.
• Createiso: xorriso를 사용하여 boot.iso에 패키지와 저장소 메타데이터를 오버레이하여 최종 dvd.iso(주로 Server 변체용)를 생성합니다.

4. 특화된 이미지 빌딩

Fedora는 비전통적인 ISO를 위해 세 가지 주요 경로를 사용합니다:

• Kiwi: 클라우드 이미지(AWS, Azure, GCP), Vagrant boxes, 컨테이너 베이스 이미지 및 WSL 이미지를 빌드합니다. XML 정의를 사용하며 kiwiBuild 작업 유형을 통해 Koji와 통합됩니다.
• Image Builder: osbuild를 기반으로 하며, Atomic Desktop ISO, Fedora IoT, Fedora Minimal를 포함한 OSTree 기반 및 bootc 기반 아티팩트를 처리합니다. JSON 매니페스트를 처리하기 위해 샌드박스화된 단계의 파이프라인을 사용합니다.
• rpm-ostree: Atomic Desktops(Silverblue, Kinoite 등)의 경우, rpm-ostree compose tree가 YAML treefiles를 기반으로 버전화되고 체크섬이 지정된 파일 시스템 트리(OSTree 커밋)를 생성합니다. comps-sync.py 스크립트는 이러한 treefiles가 표준 comps XML 정의와 동기화된 상태를 유지하도록 보장합니다.

메타데이터 및 검증

모든 컴포지션은 productmd 라이브러리를 통해 표준화된 메타데이터를 생성하여 composeinfo.json, images.json, rpms.json과 같은 파일을 생성합니다. 이 파일들은 다운스트림 도구에 매우 중요합니다. Anaconda는 설치 트리를 찾는 데 이 파일들을 사용하고, openQA는 테스트를 위한 이미지를 찾는 데 이 파일들을 사용합니다.

openQA를 이용한 자동 테스트

컴포지션이 완료되면 openQA가 가상 머신에서 이미지를 부팅하여 설치 워크플로우, 데스크톱 기능 및 업그레이드 경로를 포함한 자동화된 시나리오를 실행합니다. 야간 Rawhide 및 마일스톤 컴포지션(Beta, Final)은 항상 openQA 실행을 트리거하며, 여기서 발견된 차단 버그는 릴리스를 중단시킬 수 있습니다.

거버넌스: Changes 프로세스

Fedora 파이프라인 또는 시스템 기본값에 대한 주요 수정은 Changes 프로세스를 통해 관리됩니다. 제안은 System-Wide(FESCo 승인 및 상세한 비상 계획 필요) 또는 Self-Contained(특정 패키지에 국한됨)로 분류됩니다. 모든 변경 사항은 Rawhide에 구현되어야 하며, 릴리스에 포함되려면 특정 마감일(예: Beta Freeze)을 충족해야 합니다.

커뮤니티의 기술적 통찰

커뮤니티 논의에서는 문제 해결을 위한 이러한 엔드 투 엔드(end-to-end) 가시성의 중요성이 강조됩니다. 한 기여자는 이미지 제작 파이프라인을 이해하는 것이 버전 간에 변경되는 파일 시스템 권한 문제를 진단하는 데 필수적이라고 언급했습니다. 그러나 Koji의 클린룸 빌드와 관련하여 일부 역사적 맥락이 제공되었는데, 한 사용자는 과거에는 환경 상태로 인해 Build-Requires에 나열되지 않은 종속성이 가끔 빌드에 누출되었을 수 있지만, 현대의 반복 버전에서는 이러한 현상이 덜 흔하다고 언급했습니다.