DistributionチームのRenovate利用方法
DistributionチームがRenovateを利用している外部GitLabプロジェクト、MRの処理方法、Renovateのメンテナンスと新しい依存関係の追加に関するリソースについて説明します。
Distributionチームのインフラとメンテナンス
共通リンク
インフラ
チームのタスクの一環として、チームは以下のノード/タスクに対して責任を負います：
dev.gitlab.org: この内部GitLabインスタンスは毎晩CEパッケージを実行し、 公式パッケージのビルドに使用されます。このインスタンスがより広範なビルドパイプラインに どのように関わるかについては、ビルドインフラを参照してください。 ノードの詳細およびメンテナンスタスクは dev.gitlab.org固有のドキュメントを参照してください。ビルドマシン: 各種CIジョブでパッケージのビルドと公開に使用されるマシンをスピンアップする ランナーマネージャーマシンです。ノードの詳細およびメンテナンスタスクは ビルドマシン固有のドキュメントを参照してください。
packages.gitlab.com: GitLab Infrastructureチームが管理するセルフホスト型パッケージサーバーです。 DistributionチームがGitLab CEおよびEEのomnibus-gitlabパッケージを配布するために使用し、 Verifyチームがgitlab-runnerパッケージをユーザーに配布するためにも使用されます。 GitLab CEおよびEEパッケージはdev.gitlab.org上のCIパイプラインを通じてビルドされます。- Distributionはパッケージサーバーをツールとして使用しており、それに関連するメンテナンスタスクはありません。 パッケージサーバーは現在、Packagecloud.ioが提供するパッケージを使用して自社インフラ上にデプロイされています。 Infrastructureチームがサポートを必要とする場合、Distributionチームはベストエフォートで問題解決にあたるべきです。
gitlab.comとdev.gitlab.orgのSSH公開鍵を最新の状態に保つこと: omnibus-gitlabのCI設定は、 実行中にこれらのサーバーの公開SSHキーを使用します。キーはコードベース内（support/known_hosts）に保存されており、 いずれかが変更された場合に更新するのはチームの責任です。そのためには：bundle exec rake infrastructure:known_hosts git add support/known_hosts git commit -m "Update SSH keys"この変更は独立したMRとしてプッシュし、メンテナーにレビューを依頼してください。
外部サービス
チームのタスクの一環として、チームは以下の外部サービスを使用します：
- dependencies.io: GitLabが必要とするソフトウェアコンポーネントを自動的に更新するために使用されます。このサービスの使い方については固有のドキュメントを参照してください。
DistributionチームのインフラストラクチャーARM
ARMパッケージのビルドに使用するインフラのハードウェアと使用方法について説明します。
Distributionチームのインフラとメンテナンスーーdev.gitlab.org
dev.gitlab.orgのメンテナンスガイドライン。手動によるパッケージのアップグレード/ダウングレード、GitLab設定変更を含みます。
Distributionチームのインフラとメンテナンスーービルドインフラ
Distributionチームのビルドノードの詳細とメンテナンスタスク
