pkgbuilds
1.0.0
このリポジトリには、 garudaリポジトリに現在存在するすべてのパッケージの PKGBUILD が含まれています。 CI を多用するため GitLab 上で運用されており、読み取り専用の GitHub ミラーがあります。
独自の PKGUILD はすべてここに含まれています。歴史的に、これらは独自のリポジトリに分割されていました。正しい PKGBUILD を簡単に見つけられるようにし、より迅速にコントリビュートできるようにするために、最近、それらをこの新しいリポジトリに統合しました。構成ファイルを含むすべてのパッケージの PKGBUILD が含まれます (これはgaruda-fish-configなどの小さなファイルに適用されます)。 garuda-*-settingsパッケージなど、一部のパッケージでは、コンテンツがそれぞれのリポジトリに依然として存在する可能性があります。
パッケージングの問題や同様のことが発生した場合は、遠慮せずに問題セクションから報告してください。ここをクリックして新しいものを作成できます。
いかなる種類の貢献も大歓迎です。 ?これを行うには、次の手順に従ってください。
sudo pacman -S shfmt shellcheck経由bash ./.ci/lint.sh経由でlint.shスクリプトを実行し、コードを確認します。bash ./ci/lint.sh apply介して特定の提案を自動的に適用しますpip install --user -U Commitizen 。次に、複製されたフォルダーでcz commit実行して続行します。その後、変更を確認し、最終的にはマージします。
非推奨のパッケージが存在し、目的を果たさなくなり、システムが更新できなくなる場合もあります。これらは、 garuda-common-settingsのconflicts()とgaruda-updateの auto-pacman にパッケージを追加することで処理できます。その結果、競合により問題のあるパッケージが自動的に削除されます。
以下はビルド ツールのドキュメントから部分的に抜粋されており、このリポジトリに関係のない情報は省略されています。セットアップ手順をお探しの場合は、完全な README を参照してください。
デプロイメントは、PKGBUILD ディレクトリ内のコンテンツを変更するか、コミット メッセージに[deploy *]を追加することによって自動的にトリガーされます。 PKGBUILD チェックとは異なり、これらはmainブランチのコミットにのみ使用できます。サポートされているものは次のとおりです。
[deploy all] : 完全なgarudaルーチン、つまりこのリポジトリ内のすべての PKGBUILD をデプロイします。[deploy $pkgname] : パッケージpkgnameデプロイします。これは、これをgaruda-bash-settingsに置き換えることによって、 garuda-bash-settingsデプロイすることを意味します。これらの組み合わせのいずれかが検出されると、いくつかのチェックが正常に完了した後に展開が開始されます。過去のデプロイメントのログは、「パイプライン」セクションから検査できます。
このリポジトリは、ソースが別のリポジトリに存在する場合、使用可能な最新のタグに基づいて、すべての PKGBUILD を最新バージョンに更新する 30 分ごとのパイプラインを提供します。次に、チェックサムの更新に進み、変更をメイン ブランチにプッシュバックします。新しいデプロイメントは、コミット メッセージに[deploy *]を追加することで自動的にトリガーされます。つまり、これらのパッケージの新しいパッケージ バージョンのデプロイメントをトリガーするには、新しいタグをプッシュするだけで十分です。重要なお知らせ:
$url $pkgname $project_idに従います。後者は、GitLab API 経由で最新のタグを取得するために使用され、リポジトリの一般設定ページにあります。このジョブの最新の実行は、パイプライン セクションを参照して検査できます。スケジュールされたバッジが付いたすべてのパイプラインはタイマーによって実行されています。さらに、パイプライン スケジュール セクションを参照し、 [パイプライン スケジュールの実行] をクリックすることで、パイプラインを手動でトリガーできます。
garuda-fish-configなどの一部の PKGBUILD では、すべてのファイルがこのリポジトリに存在します。 PKGBUILD を更新するときは、対応する.SRCINFOファイルもすべて更新してください。このファイルはすべてのパッケージ関連情報の解析に使用されるためです。
パッケージの追加は、パッケージの$pkgbaseにちなんで名付けられた新しいフォルダーを作成するのと同じくらい簡単です。 PKGBUILD とその他すべての必要なファイルをここに置きます。したがって、AUR パッケージの追加は、そのリポジトリを複製して.gitフォルダーを削除するだけで簡単になります。 CI はほとんどの情報を解析するために.SRCINFOファイルに依存しているため、自己管理パッケージの場合は、.SRCINFO ファイルを適切な場所に置き、最新の状態にしておくことが重要です。最後に、基本構成を含む.CIフォルダーを追加し ( CI_PKGBUILD_SOURCEは、外部パッケージの場合に必要です。自己管理の PKBUILD は必要ありません)、変更をコミットして、変更をメイン ブランチにプッシュして戻します。その際は、従来のコミット規則に従ってください (cz-cli が役に立ちます!)。これは、次のようなコミットを意味します。
feat($pkgname): initfix($pkgname): fix xyzchore($pkgname): update PKGBUILDci(config): updateこれは、均一なコミット履歴を持つのに役立つだけでなく、変更ログの自動生成も可能にします。
これは、パッケージの PKGBUILD を含むフォルダーを削除することで実行できます。クリーンアップ ジョブは、 on-commitパイプラインの実行を通じて、古いパッケージを自動的に削除します。これにより、パッケージが生成する可能性のある分割パッケージも考慮されます。フォルダーの名前変更もパッケージの削除としてカウントされます。
新しいコミットをプッシュするたびに、CI パイプラインは次のアクションを実行します。
scheduledタグがいつ作成されたかを確認します。これは、どのパッケージをスケジュールする必要があるかを決定するために使用されます。[deploy $foldername]文字列の各コミットを解析し、既存の PKGBUILD フォルダーから派生した有効な値のみを受け入れます。 [deploy all]も有効なパラメータです。 $pkgnameスペルミスは、ここでは致命的なエラーです。問題がある場合は修正し、強制的にプッシュする必要があります。scheduledタグが更新されるため、後のパイプライン実行でそれを参照できます。30 分ごとに、スケジュールどおりのパイプラインがいくつかのタスクを実行します。
.ci/config経由で有効になっている場合).CI/configファイルを読んで、パッケージ構成に関する情報 (AUR リポジトリを管理するかどうか、PKGBUILD のソースなど) を取得します。gitlabに設定されます: GitLab リポジトリ タグから PKGBUILD を更新しますaurに設定されます。 AUR リポジトリから PKGBUILD を更新し、git リポジトリを取得して、既存のファイルを新しいファイルに置き換えます。 AUR タイムスタンプを以前に収集できなかった場合、パッケージの更新はスキップされます。gitlabまたはaurに設定されていない: CI_PKGBUILD_SOURCE で指定されたリポジトリをプルして PKGBUILD を更新しようとします。 2 回試行してもクローン作成が成功しなかった場合、更新プロセスはスキップされます。sourceセクションに設定されている git URL の最新のコミットが更新されます。異なる場合は、ビルドをスケジュールします。.CI/update.sh ) が存在する場合、それが実行されます。これは、カスタム スクリプトで PKGBUILD を更新するために使用できます。.CI/configに書き戻す (Git ハッシュなど)CI_HUMAN_REVIEWが true の場合のみ)。pkgver動的に生成する特定のパッケージに、毎日のパイプライン スケジュールが追加されました。これを利用するには、パッケージの.CI/configファイル内でCI_ON_TRIGGER=dailyを設定します。
パッケージをスケジュールに手動で追加するには、パイプラインの実行ページに移動し、[パイプラインの実行] を選択し、値としてパッケージ名を持つ変数としてPACKAGESを追加します。その後、パイプラインがパッケージを取得してスケジュールします。 PACKAGES allに設定して、すべてのパッケージをスケジュールすることもできます。 1 つまたは複数のパッケージをスケジュールする場合は、 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/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 パッケージは、 .CI_CONFIG使用して自動化された方法で、このリポジトリ経由で管理することもできます。これは、スケジュールされた各パイプラインおよびオンコミット パイプラインの後に、PKGBUILD フォルダーのファイルに加えられた変更を反映するために AUR リポジトリが更新されることを意味します。 AUR メンテナンスに関係のないファイル ( .CIフォルダーなど) は省略されます。コミット メッセージは、コミットが CI パイプラインによって作成されたという事実を反映しており、ソース リポジトリのコミット履歴へのリンクと、更新コミットをトリガーしたパイプライン実行が含まれています。
これは、CI パイプラインを介して自動的に行われます。テンプレート リポジトリで変更が検出されると、すべてのファイルが現在のバージョンに更新されます。
これは、無効なパッケージ名を指定した場合など、いくつかの理由で発生する可能性があります。これにより、 scheduledタグが更新されなくなります。この場合、スケジュールどおりのパイプラインは実行できません。スケジュールどおりのパイプラインを再度実行するには、最後のオンコミット パイプラインを修正する必要があります。ただし、 scheduledタグはスケジュール パラメータが生成されるとすぐに更新されるため、ビルドの失敗は考慮されません。このような場合、修正されたコミットを強制的にプッシュすることが積極的に推奨されます。別のコミットをプッシュすると、CI が見逃した以前のコミットを評価することになり、同じ問題が再び発生することに気づき、サイレントに続行するのではなく救済することになります。これは、障害が見落とされるのを防ぐための設計上の決定です。
まれに、ビルド キューのリセットが必要になる場合があります。これを行うには、中央の Redis インスタンスをシャットダウンし、そのダンプを削除し、そのサービスを再起動します。
このツールは Docker コンテナとして配布され、マネージャー インスタンスとビルダー インスタンスのペアで構成されます。
registry.gitlab.com/garuda-linux/tools/chaotic-manager/managerregistry.gitlab.com/garuda-linux/tools/chaotic-manager/builderinterfere.sh 、 database.shなど) が含まれています。マネージャーは、GitLab CI のschedule-packageジョブで使用され、パッケージをビルド キューに追加することでパッケージをスケジュールします。ビルダーは、コンテナーを実行できる任意のマシンで使用できます。中央の Redis インスタンスから利用可能なジョブを選択します。
このリポジトリは NixOS フレークを備えており、コミット前のフックやチェック、必要なユーティリティなどの必要なものを direnv 経由で自動的にセットアップするために使用できます。これには、 shellcheckおよびshfmtによる PKGBUILD のチェックが含まれます。必要なのはnix (パッケージマネージャー) と direnv です。その後、 direnv allow実行することで環境に入ることができます。
