pkgbuilds

가루다 리눅스 PGBUILD

이 저장소에는 현재 garuda 저장소에 있는 모든 패키지에 대한 PKGBUILD가 포함되어 있습니다. CI를 광범위하게 사용하기 때문에 GitLab에서 운영되며 읽기 전용 GitHub 미러가 있습니다.

이 저장소의 범위

우리의 모든 PKGBUILD가 여기에 포함되어 있습니다. 역사적으로 이들은 자체 저장소로 분할되었습니다. 올바른 PKGBUILD를 더 쉽게 찾고 더 빠르게 기여할 수 있도록 최근에 이를 이 새로운 저장소에 통합했습니다. 구성 파일을 포함한 모든 패키지의 PKGBUILD가 포함됩니다(이는 garuda-fish-config 와 같은 더 작은 파일에 적용됩니다). garuda-*-settings 패키지와 같은 일부 패키지의 경우 콘텐츠는 해당 저장소에서 계속 찾을 수 있습니다.

문제를 발견하셨나요?

포장 문제나 이와 유사한 문제가 발생하는 경우 주저하지 말고 문제 섹션을 통해 신고해 주세요. 여기를 클릭하여 새 계정을 만들 수 있습니다.

어떻게 기여하나요?

우리는 어떤 종류의 기여든 높이 평가합니다! ? 그렇게 하려면 다음 단계를 따르십시오.

• 이 저장소의 포크를 만듭니다.
• 포크를 로컬로 복제합니다(짧은 Git 튜토리얼).
• PKGBUILD 또는 소스 코드에 원하는 변경 사항을 추가합니다.
• shellcheck 및 shfmt가 변경된 파일에 문제가 없는지 확인하십시오.
  • 필요한 종속성을 먼저 설치해야 합니다. sudo pacman -S shfmt shellcheck 를 통해
  • bash ./.ci/lint.sh 를 통해 lint.sh 스크립트를 실행하고 코드를 확인하세요.
  • bash ./ci/lint.sh apply
• 기존 커밋 메시지를 사용하여 커밋하고 변경 사항을 포크로 다시 푸시합니다.
  • commitizen 애플리케이션은 적합한 커밋 메시지를 생성하는 데 도움이 됩니다. 현재 Arch 저장소에는 pip install --user -U Commitizen 패키지가 없으므로 pip를 통해 설치할 수 있습니다. 그런 다음 복제된 폴더에서 cz commit 실행하여 진행합니다.
• 기본 저장소에서 새로운 병합 요청을 생성하세요.
• 파이프라인 실행이 실패했는지 확인하고 최종 제안을 적용합니다.

그런 다음 변경 사항을 검토하고 최종적으로 병합합니다.

특정 포장 문제 처리

더 이상 사용되지 않고 손상된 패키지

더 이상 쓸모가 없으며 시스템을 업데이트할 수 없게 만드는 더 이상 사용되지 않는 패키지의 경우가 있습니다. 이는 garuda-common-settings 의 conflicts() 및 garuda-update 의 auto-pacman에 패키지를 추가하여 처리할 수 있습니다. 결과적으로 문제가 있는 패키지는 충돌로 인해 자동으로 제거됩니다.

CI/빌드 도구

다음은 빌드 도구 문서에서 부분적으로 가져온 것이며 이 저장소와 관련되지 않은 정보는 생략되었습니다. 설정 지침을 찾고 있는 경우 대신 전체 README를 참조하세요.

일반적인

PKGBUILD 디렉터리 내부의 콘텐츠를 변경하거나 커밋 메시지에 [deploy *] 추가하면 배포가 자동으로 트리거될 수 있습니다. PKGBUILD 검사와 달리 이는 main 분기의 커밋에만 사용할 수 있습니다. 지원되는 것은 다음과 같습니다:

• [deploy all] : 이 저장소의 모든 PKGBUILD를 의미하는 전체 garuda 루틴을 배포합니다.
• [deploy $pkgname] : pkgname 패키지를 배포합니다. 즉, 이를 garuda-bash-settings 로 바꾸면 garuda-bash-settings 배포하게 됩니다.

이러한 조합 중 하나라도 감지되면 몇 가지 확인이 성공적으로 완료된 후 배포가 시작됩니다. 과거 배포 로그는 파이프라인 섹션을 통해 검사할 수 있습니다.

자동 범프

이 저장소는 사용 가능한 최신 태그를 기반으로 소스가 다른 저장소에 있는 경우 모든 PKGBUILD를 최신 버전으로 업데이트하는 30분 간격의 파이프라인을 제공합니다. 그런 다음 체크섬 업데이트를 진행하고 변경 사항을 기본 분기로 다시 푸시합니다. 커밋 메시지에 [deploy *] 추가하면 새 배포가 자동으로 트리거됩니다. 즉, 해당 패키지에 대한 새 패키지 버전의 배포를 트리거하려면 새 태그를 푸시하는 것만으로도 충분합니다. 중요한 공지:

• 이 저장소에 모든 파일이 있는 패키지에는 적용되지 않습니다.
• 태그 앞에는 v가 붙어서는 안 됩니다.
• 패키지 소스에 대해 필요한 정보는 SOURCES 파일을 통해 제공됩니다. 각 줄은 $url $pkgname $project_id 구성표를 따릅니다. 후자는 GitLab API를 통해 최신 태그를 검색하는 데 사용되며 저장소의 일반 설정 페이지에서 찾을 수 있습니다.

이 작업의 최신 실행은 파이프라인 섹션을 찾아 검사할 수 있으며, 예약된 배지가 있는 모든 파이프라인은 타이머에 의해 실행되었습니다. 또한 파이프라인 일정 섹션을 탐색하고 파이프라인 일정 실행 을 눌러 파이프라인을 수동으로 트리거할 수 있습니다.

수동으로 버전 업데이트

garuda-fish-config 와 같은 일부 PKGBUILD의 경우 모든 파일이 이 저장소에 있습니다. PKGBUILD를 업데이트할 때 해당 .SRCINFO 파일도 업데이트해야 합니다. 이 파일은 모든 패키지 관련 정보를 구문 분석하는 데 사용됩니다!

패키지 추가

패키지를 추가하는 것은 패키지의 $pkgbase 이름을 딴 새 폴더를 만드는 것만큼 쉽습니다. PKGBUILD 및 기타 모든 필수 파일을 여기에 넣습니다. 따라서 AUR 패키지를 추가하는 것은 저장소를 복제하고 .git 폴더를 제거하는 것만큼 간단합니다. CI는 .SRCINFO 파일을 사용하여 대부분의 정보를 구문 분석하므로 자체 관리 패키지의 경우 해당 파일을 최신 상태로 유지하는 것이 중요합니다. 마지막으로 기본 구성이 포함된 .CI 폴더를 추가하고(외부 패키지, 자체 관리형 PKBUILD에 필요하지 않은 경우 CI_PKGBUILD_SOURCE 가 필요함) 변경 사항을 커밋하고 변경 사항을 기본 분기로 다시 푸시합니다. 그렇게 하는 동안 일반적인 커밋 규칙을 따르십시오(cz-cli가 도움이 될 수 있습니다!). 이는 다음과 같은 커밋을 의미합니다.

• feat($pkgname): init
• fix($pkgname): fix xyz
• chore($pkgname): update PKGBUILD
• ci(config): update

이는 균일한 커밋 기록을 유지하는 데 도움이 될 뿐만 아니라 자동 변경 로그 생성도 가능하게 합니다.

패키지 제거

패키지의 PKGBUILD가 포함된 폴더를 제거하면 됩니다. 그런 다음 정리 작업은 on-commit 파이프라인 실행을 통해 사용되지 않는 패키지를 자동으로 제거합니다. 또한 패키지가 생성할 수 있는 분할 패키지도 고려됩니다. 폴더 이름을 바꾸는 것도 패키지 제거로 간주됩니다.

온 커밋 파이프라인

새 커밋을 푸시할 때마다 CI 파이프라인은 다음 작업을 수행합니다.

• 마지막으로 scheduled 태그가 생성된 시기를 확인합니다. 이는 예약해야 할 패키지를 결정하는 데 사용됩니다.
• [deploy $foldername] 문자열에 대한 각 커밋을 구문 분석하여 기존 PKGBUILD 폴더에서 파생된 유효한 값만 허용합니다. [deploy all] 도 유효한 매개변수입니다. 여기서 $pkgname 철자를 틀리는 것은 치명적인 오류입니다. 모든 문제를 해결하고 강제로 푸시해야 합니다.
• 그런 다음 변경된 파일을 구문 분석합니다. 여기에는 제거된 패키지도 포함됩니다. 관련 폴더 내용이 변경되면 해당 패키지가 배포됩니다.
• 마지막 작업은 일정 매개변수를 구축하고(아티팩트를 통해 예약된 작업에 전달) 이전 단계가 감지될 경우 사용되지 않는 모든 패키지를 제거하는 것입니다.
• 이러한 작업이 모두 성공하는 경우 scheduled 태그가 업데이트되므로 나중에 파이프라인 실행에서 이를 참조할 수 있습니다.

일정대로 파이프라인

30분마다

30분마다 일정에 따른 파이프라인은 몇 가지 작업을 수행합니다.

• 템플릿 저장소에서 CI 템플릿 업데이트( .ci/config 통해 활성화된 경우)
• 예약된 태그가 존재하지 않거나 예약된 태그가 HEAD를 가리키지 않는지 확인하세요(이 경우 미션 중단!)
• 패키지 상태가 포함된 .state 작업 트리가 있는지 확인하고, 있으면 이를 설정합니다. 그렇지 않으면 처음부터 다시 생성합니다(예: 강제 푸시 시).
• 마지막 커밋이 자동화되었는지 확인하세요("chore(packages): update packages [skip ci]" 포함). 그렇다면 일정에 따른 커밋이 이를 덮어써 커밋 기록을 깨끗하게 유지합니다.
• 패키지의 AUR 타임스탬프를 수집하여 PKGBUILD가 변경되었는지 확인
• 각 유효한 패키지를 반복하고 다음 작업을 수행합니다.
  • .CI/config 파일을 읽어 패키지 구성에 대한 정보를 얻습니다(예: AUR 저장소 관리 여부, PKGBUILD 소스 등).
  • 다음과 같은 경우에는 PKGBUILD를 업데이트하세요.
    • CI_PKGBUILD_SOURCE가 gitlab 으로 설정되었습니다. GitLab 저장소 태그에서 PKGBUILD를 업데이트합니다.
    • CI_PKGBUILD_SOURCE가 aur 로 설정됩니다. AUR 저장소에서 PKGBUILD를 업데이트하여 git 저장소를 가져오고 기존 파일을 새 파일로 바꿉니다. AUR 타임스탬프를 더 일찍 수집할 수 없는 경우 패키지 업데이트를 건너뜁니다.
    • CI_PKGBUILD_SOURCE가 gitlab 또는 aur 로 설정되지 않았습니다. CI_PKGBUILD_SOURCE에 지정된 저장소를 가져와서 PKGBUILD 업데이트를 시도합니다. 2번 시도 후에도 복제에 실패하면 업데이트 프로세스를 건너뜁니다.
  • 패키지 구성 변수에 CI_GIT_COMMIT가 설정된 경우 PKGBUILD의 source 섹션에 설정된 git URL의 최신 커밋이 업데이트됩니다. 다르다면 빌드를 예약하세요.
  • 사용자 정의 후크가 있는 경우(패키지 디렉터리 내의 .CI/update.sh ) 실행됩니다. 이는 사용자 정의 스크립트로 PKGBUILD를 업데이트하는 데 사용할 수 있습니다.
  • 필요한 변수를 .CI/config 에 다시 작성(예: Git 해시)
• 사소한 변경의 경우 PKGBUILD를 자동으로 업데이트하고, 주요 업데이트의 경우 검토용 PR을 생성합니다( CI_HUMAN_REVIEW 가 true인 경우에만).
  • diff가 실제로 현재 PKGBUILD 폴더와 AUR PKGBUILD 저장소 간의 변경 사항을 보고하는 경우에만 업데이트가 고려됩니다.
  • 소스 파일에 대한 모든 변경 사항이 감지되지만 패키지가 빌드하는 업스트림 프로젝트 소스의 악의적인 변경 사항은 감지되지 않습니다 .
• 상태 작업 트리가 새로운 정보로 업데이트됩니다.
• 일정 매개변수가 구축되어 아티팩트를 통해 예약된 작업으로 전달됩니다.
• 사용되지 않는 분기(예: 병합된 리뷰 PR)가 제거됩니다.
• 예약된 태그가 다시 업데이트됩니다.

일일

pkgver 동적으로 생성하는 특정 패키지에 대한 일일 파이프라인 일정이 추가되었습니다. 이를 활용하려면 패키지의 .CI/config 파일 내에서 CI_ON_TRIGGER=daily 설정하세요.

수동 예약

git 커밋 없이 패키지 예약

파이프라인 실행 페이지로 이동하여 "파이프라인 실행"을 선택하고 패키지 이름을 값으로 사용하여 PACKAGES 변수로 추가하여 패키지를 일정에 수동으로 추가할 수 있습니다. 그러면 파이프라인이 패키지를 선택하고 예약합니다. PACKAGES all 로 설정하여 모든 패키지를 예약할 수도 있습니다. 하나 이상의 패키지가 예약되는 경우 pkgname1:pkgname2:pkgname3 형식을 따라야 합니다.

주문형으로 예약된 파이프라인 실행

파이프라인 실행 페이지로 이동하여 "파이프라인 실행"(재생 기호)을 선택하면 됩니다. 파이프라인 로그를 얻을 수 있는 파이프라인 페이지에 대한 링크가 제공됩니다.

간섭 추가

PKGBUILD 폴더의 .CI 폴더에 필요한 간섭 파일을 넣습니다.

• prepare : chroot 빌드가 설정된 후 실행되는 스크립트입니다. 컴파일이 시작되기 전에 환경 변수를 소싱하거나 다른 사항을 수정하는 데 사용할 수 있습니다.
  • 실제 컴파일 프로세스 전에 무언가를 설정해야 하는 경우 예를 들어 다음을 삽입하여 명령을 푸시할 수 있습니다. $CAUR_PUSH 'source /etc/profile' . 마찬가지로 패키지 충돌도 해결될 수 있습니다. 다음과 같습니다: $CAUR_PUSH 'yes | pacman -S nftables' (간섭하는 동안이 아니라 게스트의 런타임에서 변수/파이프를 평가하기를 원하기 때문에 작은따옴표가 중요합니다)
• interfere.patch : 많은 변경이 필요한 경우 여러 파일 또는 PKGBUILD를 수정하는 데 사용할 수 있는 패치 파일입니다. 모든 변경 사항을 이 파일에 추가해야 합니다.
• PKGBUILD.prepend : 이 파일의 내용이 PKGBUILD의 시작 부분에 추가됩니다.
• PKGBUILD.append : 이 파일의 내용이 PKGBUILD 끝에 추가됩니다. 이 파일에 고정된 build() 추가하면 build() 쉽게 수정할 수 있습니다. 이는 모든 종류의 수정에 사용될 수 있습니다. 배열에 무언가를 추가해야 하는 경우 makedepend+=(somepackage) 만큼 쉽습니다.
• on-failure.sh : 빌드가 실패할 경우 실행되는 스크립트입니다.
• on-success.sh : 빌드가 성공하면 실행되는 스크립트입니다.

범핑 패키지

이제 필요한 변수 CI_PACKAGE_BUMP .CI/config 에 추가하여 이 작업을 수행합니다. 자세한 내용은 아래를 참조하세요.

종속성 트리

CI는 종속성 트리를 자동으로 구축합니다. 이는 CI 아티팩트로 Chaotic 관리자에 전달되며 일정 명령이 실행될 때마다 읽혀집니다. 수동 개입이 필요하지 않습니다.

.CI/구성

각 패키지 디렉터리 내의 .CI/config 파일에는 파이프라인을 제어하고 프로세스를 빌드하는 데 사용되는 추가 플래그가 포함되어 있습니다.

• CI_MANAGE_AUR : 이 변수를 true 로 설정하면 CI는 변경 사항이 발생할 경우 파이프라인 실행이 끝날 때 해당 AUR 저장소를 업데이트합니다(CI 관련 파일 생략).
• CI_PACKAGE_BUMP : CI_MANAGE_AUR true 로 설정되지 않은 모든 패키지에 대한 패키지 범프를 제어합니다. 이 변수가 +1 증가할 때마다 pkgrel 0.1 씩 증가합니다.
• CI_PKGBUILD_SOURCE : 원격 저장소에서 업데이트된 파일을 가져오는 데 사용되는 모든 PKGBUILD 관련 파일의 소스를 설정합니다. 현재 유효한 값은 다음과 같습니다.
  • gitlab : GitLab 저장소 태그에서 PKGBUILD를 가져옵니다. gitlab:$PROJECT_ID 형식을 따라야 합니다. ID는 저장소 설정 일반 섹션을 탐색하여 얻을 수 있습니다.
  • aur : AUR 저장소에서 PKGBUILD를 가져와 git 저장소를 가져오고 기존 파일을 새 파일로 바꿉니다.
• CI_ON_TRIGGER : 특별 일정 트리거가 해당 패키지를 예약해야 하는 경우 제공될 수 있습니다. 값을 daily 로 설정하여 매일 패키지를 예약하는 데 사용할 수 있습니다. 이는 "$TRIGGER == $CI_ON_TRIGGER"인지 확인하므로 파이프라인 일정을 사용하고 TRIGGER midnight 으로 설정하고 피팅 일정을 추가하고 영향을 받는 모든 패키지에 대해 CI_ON_TRIGGER midnight 으로 설정하여 사용자 지정 일정을 생성할 수 있습니다.
• CI_REBUILD_TRIGGERS : 이 변수에 재빌드를 유발하는 것으로 알려진 패키지를 추가합니다. 패키지 버전을 추적할 리포지토리 목록은 리포지토리의 CI_LIB_DB 매개변수를 통해 제공됩니다. 각 패키지 버전은 해시되어 .ci/lib.state 에 덤프됩니다. 예약된 각 파이프라인 실행은 해시 불일치를 확인하여 버전을 비교하고 CI_PACKAGE_BUMP 통해 영향을 받는 각 패키지를 충돌시킵니다.
• BUILDER_CACHE_SOURCES : 빌드 간에 소스를 캐시해야 하는 경우 true 로 설정할 수 있습니다. 이는 느린 소스나 항상 사용할 수 없는 소스의 경우 유용할 수 있습니다. 소스는 1개월 후에 자동으로 지워집니다. 이는 패키지가 제거되거나 소스가 변경되는 경우에 중요합니다.

AUR 패키지 관리

AUR 패키지는 .CI_CONFIG 사용하여 자동화된 방식으로 이 저장소를 통해 관리할 수도 있습니다. 즉, 예약된 각 파이프라인과 커밋 중인 파이프라인 후에 AUR 저장소가 PKGBUILD 폴더 파일에 대한 변경 사항을 반영하도록 업데이트됩니다. AUR 유지 관리와 관련이 없는 파일(예: .CI 폴더)은 생략됩니다. 커밋 메시지는 커밋이 CI 파이프라인에 의해 생성되었다는 사실을 반영하며 소스 저장소의 커밋 기록에 대한 링크와 업데이트 커밋을 트리거한 파이프라인 실행을 포함합니다.

CI 스크립트 업데이트

이는 CI 파이프라인을 통해 자동으로 수행됩니다. 템플릿 저장소에서 변경 사항이 감지되면 모든 파일이 현재 버전으로 업데이트됩니다.

문제 및 파이프라인 실패

마지막 커밋 파이프라인이 실패했습니다.

이는 잘못된 패키지 이름을 제공하는 등 몇 가지 이유 때문에 발생할 수 있습니다. 이로 인해 scheduled 태그가 업데이트되지 않습니다. 이 경우 일정에 따른 파이프라인을 실행할 수 없습니다. 일정에 따른 파이프라인을 다시 실행하려면 먼저 마지막 커밋 파이프라인을 수정해야 합니다. 그러나 예약 매개변수가 생성되자마자 scheduled 태그가 이미 업데이트되므로 빌드 실패는 고려되지 않습니다. 이러한 경우 수정된 커밋을 강제로 푸시하는 것이 적극적으로 권장됩니다. 다른 커밋을 푸시하면 CI가 놓친 이전 커밋을 평가하게 되어 자동으로 계속하는 대신 동일한 문제를 다시 인식하고 구제 조치를 취할 수 있기 때문입니다. 이는 실패를 간과하지 않도록 하기 위한 설계 결정이었습니다.

빌드 대기열 재설정

빌드 대기열 재설정이 필요한 드문 경우가 있을 수 있습니다. 중앙 Redis 인스턴스를 종료하고 덤프를 제거한 후 서비스를 다시 시작하면 됩니다.

혼돈의 관리자

이 도구는 Docker 컨테이너로 배포되며 한 쌍의 관리자 및 빌더 인스턴스로 구성됩니다.

• 관리자: registry.gitlab.com/garuda-linux/tools/chaotic-manager/manager
• 빌더: registry.gitlab.com/garuda-linux/tools/chaotic-manager/builder
  • 여기에는 interfere.sh , database.sh 등과 같은 인프라 3.0에서 알려진 패키지 빌드(여기 참조) 뒤에 있는 실제 논리가 포함되어 있습니다.
  • 관리자 인스턴스가 관리하는 Redis 인스턴스에서 빌드할 패키지를 선택합니다.

관리자는 schedule-package 작업에서 GitLab CI에 의해 사용되며, 패키지를 빌드 대기열에 추가하여 패키지를 예약합니다. 빌더는 컨테이너를 실행할 수 있는 모든 머신에서 사용할 수 있습니다. 중앙 Redis 인스턴스에서 사용 가능한 작업을 선택합니다.

개발 설정

이 저장소에는 direnv를 통해 자동으로 사전 커밋 후크 및 검사와 필요한 유틸리티를 설정하는 데 사용할 수 있는 NixOS 플레이크가 포함되어 있습니다. 여기에는 shellcheck 및 shfmt 통한 PKGBUILD 확인이 포함됩니다. nix (패키지 관리자)와 direnv가 필요하며, 그 후 direnv allow 실행하여 환경에 들어갈 수 있습니다.