Auto: 1つのリポジトリに複数のパッケージマネージャープラグイン

もう少し考えてみると、新しいトップレベルの構成オプションを導入する方が理にかなっていると思います。

{
  // Still have some global config at root
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  // Plugins used for every package
  "plugins": ["conventional-commits"],
  "packages": [
    // Target specific directories and apply a set of plugins to them
    {
      "target": "www",
      "plugins": ["git-tag"]
    },
    {
      "target": "api",
      "plugins": ["npm"]
    },
    // Specify a pattern or even and array of patterns or directories
    {
      "target": ["packages/**",  "utils"],
      "plugins": ["npm"]
    },
    {
      "target": "web-store",
      "plugins": [
        "chrome-web-store",
        // Whole lifecycle is run for each package so you can have package plugins
        ["upload-assets", { "assets": ["./path/to/file"] }]
      ]
    }
  ]
}

これを実現するには、イテレータ関数を使用して複数のものでshipitを実行し、同じ量のコミットを生成できると思います。

最新の例：

1. すべて同時に実行する
2. 変更ログをコミットする前の利回り
3. 変更ログを一度にコミットする
4. バージョンがぶつかるまでの利回り
5. 必要に応じてバージョンをコミットする
6. 最後まで実行

この設定で、あなたは本当にすべて一緒にlernaをスキップすることができます

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "packages/**",
      "plugins": ["npm"]
    }
  ]
}

package一致するコミットがない場合、リリースは行われません。 これにより、 lernaを使用せずに、はるかに簡単な方法で独立したモノレポ管理が実現します。 固定バージョンのmonorepoが必要な場合は、従来のルートを使用するのがよいでしょう。

これのもう1つの優れた機能は、異なるバージョン管理スキーム（ fixedとindependent ）を使用してリポジトリに2つのleranプロジェクトを含めることができることです。

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "fixed-monorepo",
      "plugins": ["npm"]
    },
    {
      "target": "independent-monorepo",
      "plugins": ["npm"]
    }
  ]
}

これは、1つのリポジトリでchrome-web-storeプラグインとnpmプラグインを使用できることを意味します。

同じプロジェクトで両方を使用することは_できない_という意味だと思いますか？

各プラグインは現在、コミット、タグ付け、およびプッシュを行っています。 これにより、多くのノイズが発生します。 おそらくそれらのgitアクションをコアに移動する必要があるので、それは一度だけ起こりますか？ ただし、パッケージごとに個別のコミットが必要になる場合があります。

ハイブリッドアプローチを行うことは理にかなっているかもしれません。 各プラグインがコミットするかもしれませんが、プッシュするのは1回だけですか？

各フォルダが独自のパッケージリリースである世界で、タグがどのように機能するかはよくわかりません。 作成するバージョンごとにタグを作成しますか？ 最後に作りますか？

もう少し考えてみると、新しいトップレベルの構成オプションを導入する方が理にかなっていると思います。

パッケージごとにリリースエクスペリエンスをカスタマイズできるというアイデアが気に入っています。 docsパッケージとライブラリパッケージのs3 / ghページのデプロイを管理できることのいくつかの利点を確実に理解できます。

処理する必要があるのは、複数のリリースパイプラインにパッケージを含めることです。 次の場合はどうなりますか。

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "packages/**",
      "plugins": ["npm"]
    },
    {
      "target": "packages/chrome-ext",
      "plugins": ["chrome-web-store"]
    },
  ]
}

chrome-extパッケージはnpmとwebstore両方に公開されますか？ または、最初に宣言されているため、 npmリリースが勝ちますか？

各フォルダが独自のパッケージリリースである世界で、タグがどのように機能するかはよくわかりません。 作成するバージョンごとにタグを作成しますか？ 最後に作りますか？

レルナの振る舞いに合わせることができると思います。 1回のコミットでたくさんのタグがあります。 その後、各タグは独自のリリースになります

chrome-extパッケージはnpmとウェブストアの両方に公開されますか？ それとも、最初に宣言されているため、npmリリースが勝ちますか？

その場合、はい、両方を実行しようとします。 しかし、それは単に悪い構成です。 これを機能として使用して、パッケージを2つの異なるレジストリ（例：npmとgithubパッケージレジストリ）に公開すると言うことができます。

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "packages/**",
      "plugins": [["npm", { registry: "https://npm" }]]
    },
    {
      "target": "packages/**",
      "plugins": [["npm", { registry: "https://github-package-registry" }]]
    },
  ]
}

これは面白そうですね...そして複雑です😅

私は一般的に👍検出で過度に賢くしようとするよりも構成を持っています（それは予期しない方法で故障し、テストするのが難しいためです）。

私の最初の質問は、これのデフォルトの状態がどのように見えるかということだと思います。 npmプラグインがある場合、それが機能する前に構成を追加する必要がありますか？ 他の人と同じ質問。

gitインタラクションに関しては、gitインタラクションは一般的にプラグインパイプラインの一部である必要があるように思われます。 プラグインがコミットを実行する必要がある場合は、コミット可能なフックを利用できる必要があります。 プッシュは、CIの実行方法などに影響を与えるため、コアでのみ処理する必要があります。

npmプラグインがある場合、それが機能する前に構成を追加する必要がありますか？

今日機能する構成は、 packages世界で機能するはずです。 したがって、変更は必要ありません。 重大な変更のほとんどはノードAPI側であり、通常のユーザーには表示されません。

プラグインがコミットを実行する必要がある場合は、コミット可能なフックを利用できる必要があります。

私はこの考えが好きです。 このgitインタラクションをauto内で形式化すると、おそらく便利です。 そして、彼らがこのフックを使用しない場合、それはもう少しノイズを意味します（例：追加のコミットと追加のプッシュ）

私はまた、モノレポでAutoを使用する方法を考えていて、あなたのニーズに合うかもしれないわずかに異なるアプローチを思いつきました。

基本的に、モノリポジトリが1つある場合は、各サブプロジェクトに必要なプラグインをセットアップできる独自の.autorcファイルを持つ複数のサブディレクトリを作成できます。

次に、必要に応じて各プロジェクトを異なる時間にリリースできるように、プロジェクトごとに異なるプレフィックスを付けることを選択できます。 たとえば、sub-project1のリリースにsub-project/v1.4.5タグを付け、別のプロジェクトにsub-project2/v9.9.9タグを付けることができます。

Autoは、 git describe --tags --matches "sub-project1/*"ようなものを使用して、それに応じて各プロジェクトのタグを取得および更新できます。

ちょっとした考え。

それは実際、私が取っているアプローチにかなり近いものです。 私は
今週取り組んでいます。

これまでのところ、いくつかのコマンドにそのフラグを追加する必要がありました（—一致）。
かなり順調に進んでいます。

私は「パッケージ」フィールドアプローチを採用しましたが、基本的には
「autorc」の配列

プレフィックスを取得するために、名前を提供するプラグインのフックを追加しました。 この
プラグインがマルチパッケージ互換である場合、自動へのシグナル伝達にも役立ちます

2020年1月29日水曜日午後9時11分アレハンドロバリエントス<
[email protected]>は次のように書いています：

モノレポでオートの使い方も考えていて思いついた
あなたのニーズに合うかもしれないわずかに異なるアプローチ。

基本的に、モノレポが1つある場合は、複数のサブディレクトリを持つことができます。
それぞれに独自の.autorcファイルがあり、プラグインをセットアップできます。
各サブプロジェクトが必要になります。

次に、プロジェクトごとに異なるプレフィックスを設定して、次のようにすることができます。
各プロジェクトは、必要に応じて異なる時間にリリースできます。 たとえば、
sub-project1のリリースは、sub-project /v1.4.5および
別のプロジェクトは、タグsub-project2 /v9.9.9を取得します

Autoは、git describe --tags--matchesのようなものを使用できます。
「sub-project1 / *」を使用して、各プロジェクトのタグを取得および更新します。

ちょっとした考え。

—
スレッドを作成したため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/intuit/auto/issues/917?email_source=notifications&email_token=AAJDEBGUZR5HF6P3OKRILTDRAJOOXA5CNFSM4KMLWYF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AAJDEBDX72NB5Z7ZJPTDHVLRAJOOXANCNFSM4KMLWYFQ
。

戻ってこれをもう一度読んで、私は実際にかなり興奮しています！ パッケージ名の前に付けられた複数のタグは本当に良い音です。 また、私はpackagesフィールドが本当に好きです。

@hipstersmoothie今日、

@vincentbrigliaは、GitHubパッケージに公開するプラグインが機能しますか？ npmプラグインからかなり便乗する可能性があります。 nextとlatestリリースは簡単ですが、カナリアはあまり意味がありません。 考え？

@hipstersmoothie同じパッケージをNPMレジストリとGHPRレジストリに公開する場合があります。 ここでの理由は、GHPRは、そのように宣伝されていても、パッケージを正しくプロキシしないためです。 根本的な問題は、npmとgithubで同じスコープを使用していることです。

私たちは主に密室で開発を行っており、カナリアビルドを使用して、 feature branches > nextから設計チームと会話/承認を行っているため、カナリアビルドはこのコンテキストでも引き続き役立ちます。 npmプラグインは現在この機能を提供しているので、それを失うのは残念です。

GHPRを使用する場合のコンテキストは、一般に、それがプライベートな「組織」コンテキストで公開する主要な場所であり、コンポーネントを公開する場合は、npmjs.orgがセカンダリであると思います。 （私は誰もgithubからパブリックコンポーネントをインストールするのを見たことがありません）。 オープンソースのコンテキストでは、通常はnpmjsであり、GHPRやその他のプライベートパッケージレジストリはありません。

ちなみに、特定のGHPRプラグインについて言及しているので、次の週に、いくつかのルールに基づいてパッケージバージョンを削除する自動プラグインを作成する時間を確保しました（組織は50Gbのパッケージに制限されており、Dockerが含まれています）画像）

• 範囲内の最後のカナリアを削除します
• 範囲内の最後からn番目を削除します
• ..。

また、v10で作業が開始されるまで、特定のghprパブリッシャーを作成することを喜んでお待ちしています。ここで紹介するアイデアは非常にエキサイティングであり、おそらくより「将来の証拠」です。

とりあえず、パブリックとプライベートを同時に公開せずに生きることはできますが、少なくとも、これが私からのユースケースであることをご存知でしょう。

私は「セカンダリパッケージレジストリ」プラグインについてもっと考えていました。 したがって、npmプラグインはそれと同じように機能し、構成されているレジストリに公開します。 次に、この新しいプラグインは2番目のレジストリに公開し（npmかghprかは関係ありません）、HEADコミットにあるバージョンをリリースします。

ちなみに、特定のGHPRプラグインについて言及しているので、次の週に、いくつかのルールに基づいてパッケージバージョンを削除する自動プラグインを作成する時間を確保しました（組織は50Gbのパッケージに制限されており、Dockerが含まれています）画像）

これは良い機能のようです。 私はそれらの制限が存在することを知りませんでした！

この新しいプラグインは、2番目のレジストリに公開し（npmかghprかは関係ありません）、HEADコミットにあるバージョンをリリースします。

まあそれは間違いなくうまくいくでしょう！ 編集：私たちのシナリオにも

やあ！ このスレッドに関する自動の現在の状態は何ですか？ 同じリリースから複数のものを公開することは可能ですか？

各パッケージマネージャープラグインは、パッケージマネージャー用の追加ファイルに依存しているため（ git-tagを除くすべて）

これは間違った仮定だと思います。 dockerプラグインは任意のファイルに依存していますか？ 不必要かもしれないので、悪い例かもしれません。 次にもう1つあります。Autoをsbt （Scalaの最も一般的なビルドツール）で使用することに興味があり、機械可読なJSON / XML構成がありません。 sbtビルドはScalaコードで構成されており、ビルドに関する情報を抽出するには、何らかの方法でsbtと通信する必要があります。

これにより、はるかに簡単な方法で独立したモノレポ管理が実現します

また、このスレッドから、目標は、異なる公開ニーズを持つ複数のサブプロジェクトを持つモノレポプロジェクトに対応することであるように思われます。 さまざまな種類のアーティファクトを生成する単一のプロジェクトはどうですか？ たとえば、Dockerイメージと構成アーカイブ（どこかにアップロードされる予定）。 または、ライブラリとしてNPMに公開したり、GitHubリリースのアクションとして公開したりできるGitHubアクション。

各プラグインは現在、コミット、タグ付け、およびプッシュを行っています。 これにより、多くのノイズが発生します。 おそらくそれらのgitアクションをコアに移動する必要があるので、それは一度だけ起こりますか？ ただし、 packageごとに個別のコミットが必要になる場合があります。

これがプラグインの現在の実装の主な問題だと思います。 これは、各コマンドが「1つのことだけを本当にうまく行う」という主張についての私の混乱に戻ります。 私の意見では、 publishフックは、コミットを作成したりgitタグをプッシュしたりするのではなく、特定のパッケージマネージャーに対して実際に_のみ公開_する必要があります。 各パブリッシングプラグインがパッケージマネージャーの詳細の実装のみに焦点を当てることができる場合、プロセスの共通部分を再利用および/または共有できます。 Autoでこれを達成することはまだ可能ですか、それともNPMのようなプロジェクトに偏りすぎていますか？