問題タブ [renovate]

リリース バージョンとコードをソース リポジトリと一致させながら、リポジトリ内の一意のコードとリリース バージョンを更新する最善の方法を探していますが、個別のバージョン管理システム全体を作成するわけではありません。

私は、別のグループによって積極的に維持され、通常のバージョンを公開しているプロジェクトのミラー化されたレポを持っています。Renovate を使用して、MR が新しいバージョン タグでリポジトリを更新するときに、MR を監視および作成しています。これは私のコードを彼らのリリースで最新の状態に保つのにうまく機能しますが、私は彼らのコードの上に新しいものを構築しています. したがって、正確な鏡ではありません。

バージョン 1.7.0 を持っていて、それが最新の場合、自分で新しいコードをリリースすると、バージョニングがソースから逸脱します。1.7.1 を実行する必要があります。これにより、自分のプロジェクトがソース リポジトリよりも優先されますが、正しい解決策ではありません。または、1.7.0- としてタグ付けする必要があります。これが進むべき道だと思っていますが、レポのバージョン管理をソースの (major.minor.patch) バージョン管理にできるだけ近づけるための他の解決策を探しています。

特定の依存関係の「主要な」更新を自動マージしないように改装したいのですが、それらの依存関係から他の更新を自動マージする必要があります。

たとえば、renovate で eslint のすべての「マイナー」および「パッチ」更新を自動マージする場合、すべての「メジャー」更新を eslint に自動マージするべきではありません。

この要件に準拠するために、renovate json ファイルでルールを定義するにはどうすればよいですか。

docker-compose watchtower コンテナーに相当する kubernetes を探しているときに、renovate に出くわしました。docker タグ、依存関係などを更新するための普遍的なツールのようです。

また、サービス自体を kubernetes 内で実行する方法の例もあり、 kubernetesマニフェストの更新をチェックするように renovate を設定する方法のブログ投稿 (?) を見つけました。

今、私が見逃しているパズルのピースは、単一のポッドのイメージ タグを更新し、それを kubernetes クラスターにデプロイする方法を理解する、いくつかの非常に基本的な作業例です。どこかに例が必要な気がしますが、一生見つけることができません。

watchtower の説明:
docker compose セットアップで実行されているすべてのコンテナーを監視し、利用可能になったら新しいバージョンのイメージをプルして、その過程でコンテナーを更新します。

bitbucket クラウドの npm リポジトリの依存関係を自動的に更新するために、bitbucket クラウドの config.json をセットアップしようとしています。私は1つの例を見つけましたが、2つのことを理解できません:

1. エンドポイント - そこに行くべきもの (ABC)? - 当社の bitbucket 名前空間のリンクは次のようになります: https://bitbucket.org/uvxyz/

2. bitbucket パイプラインなしで renovate-bot を使用して PR を発行できますか? その場合、config.json mods を介して特定のリポジトリまたはリポジトリのみを更新するように renovate を作成できますか、または自動依存関係の更新が必要な各リポジトリに renovate.json ファイルを配置する必要がありますか?

後者の例に感謝します。