Auto: ホットフィックス-古い未成年者のパッチとパッチをサポート

@hipstersmoothie
これがどのように実装されるか/実際にどのように見えるかについての詳細はありますか？

また、 merge into a tagが何を意味するのか理解できません...明確にできる可能性がありますか？ 私の理解では、PRはブランチをターゲットとしてしか作成できませんでした。

いいえ、私は問題についてあまり考えていません。

また、タグへのマージの意味がわかりません

uiは、タグにマージできる可能性があると私に信じさせましたが、さらに検討すると、これは不可能のようです。 できれば、これが可能になります。

少し覚えていますが、これが私が考えていたものだと思います。

1. タグ1.2.3が存在し、現在のバージョンは2.0です
2. PRはタグ1.2.3になり、1.2.3-0を生成します（0はsemverのビルド部分です）

わかりました。semverのビルド部分を利用することは間違いなく理にかなっています。 👍

タグに直接PRを作成できない場合、このフローでは、リポジトリの所有者がアップストリームブランチ（PRのターゲットブランチ）のタグからブランチを作成する必要がある場合があります。 少し面倒ですが、もっと良い選択肢があるかどうかはわかりません。 さらに、これらのタイプのリリースは一般的ではない可能性が高いため、おそらくこれで問題ありません。

古いメジャーサポート（ versionBranches ）と同様のアプローチを利用して、構成でブランチプレフィックスを指定できます。 この機能は、修正プログラムタイプのリリースを対象としているように思われるため、古いメジャーサポートとは別に構成を維持することは理にかなっています。 どう思いますか？

フローの例は次のようになります。

• ユーザーは、自動構成で、プレフィックスがhotfix-ブランチのビルド識別子を使用してビルドするように指定します
• 既存のコミットログ
  <ul> <li>(tag: v2.0.0) (master)<br /> |</li> <li>(tag: v1.2.0)<br /> |</li> <li>(tag: v1.1.0)<br /> |</li> <li>(tag: v1.0.0)<br />

古いメジャーサポート（versionBranches）と同様のアプローチを利用して、構成でブランチプレフィックスを指定できます。

私はそのアイデアが好きですが、実際には、使うのがそれほど楽しいとは思いません。 autoはたくさんリリースするので、あなたは狂った数のブランチになってしまうでしょう。

タグに直接PRを作成できない場合、このフローでは、リポジトリの所有者がアップストリームブランチ（PRのターゲットブランチ）のタグからブランチを作成する必要がある場合があります。 少し面倒ですが、もっと良い選択肢があるかどうかはわかりません。 さらに、これらのタイプのリリースは一般的ではない可能性が高いため、おそらくこれで問題ありません。

私は、このタイプのリリースが標準から外れていることに同意します。 これにより、自動ブランチ作成の有用性が低下します。 たとえあったとしても、それらをそれほど使用しなくても、多くのノイズ（より多くのブランチ）が発生します。

上記の提案されたフローに関しては、それはうまくいくようです。 PRをタグにできないのは残念です！ このワークフローがずっと簡単になります。

これについて考えると、この機能を完全に具体化するには、 autoにいくつかのことが必要になる可能性があります。

1. 新しいコマンドauto hotfix ：実行すると、ブランチ内の最新のタグに基づいた新しい修正プログラムバージョンでプロジェクトがリリースされます
2. 以下のための新機能auto shipit ：私たちがしているかどうかを検出hotfixBranchと実行auto hotfix

auto hotfixがどのように機能するかについては、次のいずれかになります。

1. nextまたはcanary =>修正プログラムがサポートされているかどうかをプラグインがどのようにリリースするかを制御できる新しいフック
2. version publishフックとversion buildセンバーを解放できるようにします。

2つのオプションのうち、 version pubishフックと1傾いていると思います。 その欠点は、一部のフックがafterVersionと呼ばれず、一部のプラグインが機能しないことです。 これは現在、 canaryとnext両方で問題になっています。 彼らもそのフックを呼ばないので。 だから、すぐに心配する必要がない何か。

これを追加することに興味がありますか？

私はそのアイデアが好きですが、実際には、使うのがそれほど楽しいとは思いません。 自動リリースがたくさんあるので、あなたは狂った数のブランチになってしまうでしょう。

おっと、それはブランチプレフィックス設定を持つという点で古いメジャーサポートに似ていたことを意味しました。 ブランチを自動的に作成すると、特に頻繁にリリースする場合に、ノイズが多すぎることに間違いなく同意します😆

これについて考えると、この機能を完全に具体化するには、自動にいくつかのことが必要になる可能性があります。

1. 新しいコマンド自動修正プログラム：実行すると、ブランチ内の最新のタグに基づいた新しい修正プログラムバージョンでプロジェクトがリリースされます
2. 自動出荷の新機能：hotfixBranchにいるかどうかを検出し、自動修正プログラムを実行します

うん。 これにより、必要な変更の大部分がカプセル化されると思います。

自動修正プログラムがどのように機能するかについては、次のいずれかになります。

1. nextまたはcanaryの方法=>修正プログラムがサポートされているかどうかをプラグインがどのようにリリースするかを制御できる新しいフック
2. バージョンを再利用してフックを公開し、ビルドセンバーをリリースできるようにします

2つのオプションのうち、バージョンとpubishフックを新しい方法で呼び出すことは、重大な変更と見なされる可能性があるため、私は1に傾いていると思います。 その欠点は、一部のフックがafterVersionで呼び出されず、一部のプラグインが機能しなくなることです。 これは現在、カナリアと次の両方の問題です。 彼らもそのフックを呼ばないので。 だから、すぐに心配する必要がない何か。

高レベル、私は1も理にかなっていると思います。 どのフックがどのコマンドに対して呼び出されるかをよりよく理解するには、コードをトレースする必要がありますが、 next 、 canary 、およびhotfixすべて同様のパターンに従う場合、そうすれば、問題点は後で解決するのが簡単になるでしょう。

これを追加することに興味がありますか？

確かに👍、私は喜んでいるでしょう。
おそらく来週までこの実装を見ることができないでしょうが、この問題は3月以来更新されていないので、それは問題ないと思います。

素晴らしい！ これについては計画された作業がないので、それはあなただけです

FWIW-私は、あなたが劣った選択と見なしたことを正確に実行することによって、これをプラグインとして構築しようとしました- version-MAJOR-MINORブランチを作成します。 現在のプロセスであるTBHでは、あまりノイズのようには感じません。 リリースラインごとにブランチを作成しました。

現在のversionBranchesの大部分は、このプラグインです。

    this.hooks.beforeCommitChangelog.tapPromise(
      "Old Version Branches",
      async ({ bump }) => {
        if (bump === SEMVER.major && this.config?.versionBranches) {
          const branch = `${this.config.versionBranches}${major(
            await this.hooks.getPreviousVersion.promise()
          )}`;

          await execPromise("git", [
            "branch",
            await this.git?.getLatestTagInBranch(),
          ]);
          await execPromise("git", ["push", this.remote, branch]);
        }
      }
    );

SEMVER.minorサポートを追加するのは簡単に見えますが、自動車の他の部分を変更する必要があるかどうかはわかりません。

これは古いリリースで発生することの一部ですが、 shipitこのチェックも合格する必要があります

https://github.com/intuit/auto/blob/f37945b45b7fef6ffdb00ffa0250de449e02b883/packages/core/src/auto.ts#L1442

次にここに行き、基本的にどこからリリースの計算を開始するかをオーバーライドします

https://github.com/intuit/auto/blob/f37945b45b7fef6ffdb00ffa0250de449e02b883/packages/core/src/auto.ts#L1509

メジャーではなく古いマイナー/パッチで行う必要がある1つの考慮事項は、バージョンの不一致の可能性です。 未成年者の場合は、おそらくそれほど問題にはなりません。

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.1.1)
|
|  *  (tag: v1.1.2) <- Need to add logic to find an available tag 
| /
*  (tag: v1.1.0) (hotfix-feature)
|
*  (tag: v1.0.0)

したがって、 hotfixコマンドは必要ないかもしれません。 代わりに、一意のバージョン番号を試すことができます。 ただし、これについては検証が必要な場合があります。

ルール：

1. 古いマイナー/パッチリリースブランチでメジャーをリリースできません（必須）
2. 古いパッチリリースブランチでマイナーをリリースできません（おそらく不要ですか？）

@hipstersmoothie
次のタグが使用できない古いタグからビルドするようにciを設定している場合、デフォルトの動作がどのようになるか知っていますか？

私の推測では、このエラーがどこで発生するかはわかりませんが（おそらくタグプッシュで？）、失敗が発生するでしょうか？

NS：

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.1.1)
|
|  *   <- what is current behavior if I try to release this commit
| /
*  (tag: v1.1.0) 
|
*  (tag: v1.0.0)

@hipstersmoothieが指定したルールを適用する以外に、 try to unique version number戦略/実装に関する1つの潜在的な問題/混乱が見られます。 @hipstersmoothieが例を挙げた例では、 v1.1.2はv1.1.1からのパッチリリースとして他の人に見られますが、開発は直線的ではなかったため、これは保証されません。 v1.1.2はv1.1.1からの変更がない可能性が高いため、 v1.1.1からv1.1.2への後方互換性のない変更が存在する可能性もあります。 次の一意のバージョンがv1.1.0から離れている場合、これは悪化し、さらに混乱する可能性があります（つまり、次の一意のバージョンがv1.1.100どうなりますか？）

semverのビルドメタデータ部分を利用すると、この混乱が制限されます。これは、semverの仕様によれば、バージョンの優先順位を計算するときに無視されるためです。 ビルドメタデータ番号をインクリメントする場合は、インクリメント番号の代わりにcommitshaを使用できます。

一般に、ソフトウェア開発は必ずしも直線的ではないため、最適な実装があるかどうかはわかりません。

一般化する場合は、ブランチに関係なく、上記の戦略を指定するための何らかの構成またはフックを使用できます（またはブランチをフックするパラメーターにすることもできます）。
このように、プラグインを介してさまざまな実装を使用できます。

次のタグが使用できない古いタグからビルドするようにciを設定している場合、デフォルトの動作がどのようになるか知っていますか？

コミットのメッセージに[skip ci]れているため、通常、タグは作成されません。

次の一意のバージョンがv1.1.0からの距離が大きい場合、これは悪化し、より混乱する可能性があります。

これは素晴らしいポイントです。 間違いなく、バージョンのメタデータの構築部分を適切な戦略にします。

一般化する場合は、ブランチに関係なく、上記の戦略を指定するための何らかの構成またはフックを使用できます（またはブランチをフックするパラメーターにすることもできます）。
このように、プラグインを介してさまざまな実装を使用できます。

あなたの投稿は、一意のタグを見つけることは混乱を招くスキームであり、おそらくそうすべきではないと私に確信させました。

多分それがうまくいくかもしれないけれども私達が混合をするならば。 パッチ適用と古いマイナーは簡単なはずです。 メジャーのoldVersionBranchesとまったく同じように機能する可能性があります。

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.2.0)
|
|  *  (tag: v1.1.5) <- Can merge patched into old minor branch, maybe error when PR has `minor`
| /
*  (tag: v1.1.4) <- branch: version-1.1
|
*  (tag: v1.0.0)

次に、パッチを適用するためのメタデータのビルド部分のみを実行する必要があります。

fromオプションとuseVerionオプションがマージされた状態で、修正プログラムを実行する組み込みの方法はありますか？ 私は今日それを作らなければならなかった、そしてそれを手作業で苦痛に行うことを選んだ。

コンテキストとして、私のプロジェクトは7.7です。 私たちのプロジェクトの主要な消費者は現在、7.5のバージョンをリリースしており、問題を発見し、7.5.1が必要だったため、リリースの途中ですべてを再QAする必要はありませんでした。 最適ではありませんが、たまに発生します。

手動の介入なしに私の知る限りこれを行う方法はまだありません。 ここintuitの内部の誰かが、最終的にこれを追加することを計画していると思います。 私はこれが自動車のひどく欠けている機能であることに同意します

聞いてすごい！ ありがとう🙏

私たち（私と@ 10hendersonm）はこれに対する解決策を開発しましたが、それはかなりです
関与。 ただし、自動とプラグインのみを使用します。

PRのみを使用してプロジェクトの7.2.1、8.1.1、および8.2.2を修正しました
（非常に慎重に）。

人々が興味を持っているなら、これをどのように共有するかを調べることができますか？

木、2021年1月14日には、午前7時27分PMマットFeltenの[email protected]は書きました：

聞いてすごい！ ありがとう🙏

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/intuit/auto/issues/1054#issuecomment-760583830 、または
退会
https://github.com/notifications/unsubscribe-auth/AACI3Q6RKDONYJVH6UWUPFLSZ6KZNANCNFSM4LFJ4ULQ
。

とても興味があります！

皆さんこんにちは！ 私はこれに貢献することに興味があります。 私の提案は次のとおりです。

1. 一般に、 autoはversion-*ブランチを尊重しようとします。 たとえば、任意のブランチからversion-1.1.4へのパッチマージは、バージョン1.1.5リリースを生成します。 そのバージョンがすでに作成されている場合、NPMリリースまたはGitタグのいずれかが失敗しますが、それは正常であり、予想されるエラーケースです。
2. 私たちは、更新することができますversionBranches受け入れるように"major" | "minor" | "patch"あなたが指定した内容に基づいて、潜在的な修正プログラムの枝を生成するであろうが、。 これにより、手動でversion-*ブランチを作成する必要があるか、修正が不要なときに維持するにはブランチが多すぎるかというトレードオフを選択できます。

考え？

しかし、それは正常で予想されるエラーの場合です\

私はまだこれが何らかのタイプのバージョンを作成することを期待しています。 最近、他に何もプルしないように、特定のコミットからホットフィックスをリリースしたいというケースがありました。 この場合、上記の会話からsemverのビルド部分を使用できると思います。

versionBranchesを更新して「メジャー」を受け入れることができます| 「マイナー」| "パッチ"

現在の構成は、 trueまたは主要なブランチのプレフィックスとなる文字列のいずれかです。 新しい設定は次のようになっている必要があると思います

{
  "versionBranches": {
      "branchPrefix": "version-",
      "types": ["major", "minor"] // defaults to just major   
   }
}

答える最後の質問は、まだホットフィックスフックまたは呼び出しバージョン+公開フックであり、現在の古いバージョンのブランチ実装のコードを見て、オプション2を実行し、バージョン+公開を呼び出します（これは誤って最新のタグに公開すると思います）。

@lshadler最善のアプローチを見つけるには、しばらくの間、これをペアにする必要があります。

@bmuenzenmeyerアプローチの概要を教えてください。

実装について考えれば考えるほど、v11と、バ​​ージョンおよび公開コマンドに追加されるコンテキストが必要になると思います。

古いリリースの場合、changelog、afterVersion、および最新リリース中に呼び出されたすべてまたはそれらのフックを使用して実行するには、完全な最新のパイプラインが必要です。

おそらく、次のリリースのバージョンを同じにする必要があります。afterVersionpublishafterPublishフロー最新のもの。 それもv11の一部になる可能性があります。 同様の自動化を追加できるように、最新のワークフローと一致する必要があります。

カナリアには何もコミットされないため、カナリアのワークフローは同じままで、カナリアのフックをタップするだけでさらに多くのことができます。

みなさん、こんにちは。昨年の狂気で、残念ながらこの問題は私から遠ざかりました。

さまざまなアプローチについては、これらの機能が解決するさまざまなユースケースを検討することが役立つと思います。 私の意見では、2つのユースケースを見ることができます。

• （1）古いブランチ（つまり、古いメジャーバージョン）の長期サポート
• （2）特定のバージョンの短期サポート（例：ホットフィックス）

この会話に基づいて、これらのユースケースごとに異なるアプローチをとることは理にかなっていると思います。

（1）ブランチ/リリーストラックの長期サポートについては、 versionBranchesで解決できるはずだと思います。 マイナーバージョンでこの動作を拡張したい場合（上記のいくつかの例のように）、それはその機能の拡張である可能性があります。

（2）短期間のサポート/ホットフィックスについては、上記のスレッドに基づいて、ユーザーが常にsemverのビルド部分を使用してホットフィックスリリースを生成するための標準的な方法があるはずです。 これにより、コード所有者が使用する一貫した動作が提供され、いくつかの複雑なコーナーケースシナリオが回避されます。 この場合、新しい修正プログラムコマンドとフックを使用できると思います。 これは明確な機能強化になる可能性があります。 一般に、このユースケースは、消費者が可能であれば最新バージョンを使用するように奨励されるべきであるため、比較的まれなはずです。

edit _（短期的なユースケースでは、潜在的にversionBranches拡張して、 version-ブランチのsemverラベルを尊重するか、常に利用するかを示すパラメーター/トグル/フラグを許可することができます。 semverのビルド部分を作成し、それらのブランチのラベル​​を無視します）_

これら2つ以外に考慮すべきユースケースはありますか？

ユースケースごとに異なるアプローチを検討する必要がありますか？

（また、私はまだこれらの変更のいくつかを手伝うことができますが、他の誰かがこれのために変更を行うのを絶対にブロックしたくありません）

また、分岐パターンの接線方向の考え方：

autoは、リリース用のgitタグ（リリース）を生成します。 これは、有効なgitrefがgithubにプッシュされることを意味します。 短期サポートのユースケース（つまり、短期間のブランチ/ホットフィックスブランチ）の場合、これは、リリース/ gitタグがプッシュされた後にユーザーが短期間のブランチを削除できることを意味します。

• 次のタグを持つマスターブランチが与えられます
  <ul> <li>(tag: v1.3.0) (master)<br /> | </li> <li>(tag: v1.2.3)<br />

短命のブランチの場合、機能を追加するときに上記のブランチパターンを文書化するとよい場合があります。 私は個人的に、ブランチを削除しても新しいコミットへの参照があることに多くの人が気付いていないことを発見しました。これは、さまざまなプロジェクトが短命のブランチの乱雑さを減らすのに役立つ可能性があります。

私は最近、semverのビルド部分を利用してビルドを作成するコードをいじっていました。 そうしていると、最新のgithubリリースが必ずしも最新/最高のセマンティックバージョンであるとは限らないユースケースに出くわしました。

たとえば、 https ： v1.2.3+1と表示されv1.3.0 。

コード内のかなりの数の場所がgetLatestReleaseしているため、パイプラインがfromパラメーターを明示的に設定しない場合、これによりさまざまな動作が発生する可能性があります。 NS：

• リリースノートに含まれるもの
• 以前のバージョンはどのように計算されますか
• HEADコミットから最新のgithubリリースに到達できない場合、機能が壊れる可能性があります

私はテストしていませんが、これらのタイプのシナリオは、既存のversionBranches動作を介して到達できると思います。 これは、どのフローがgitタグ/ githubリリースを生成する必要があるかに関するコメントに関連していると思います。

答える最後の質問は、まだホットフィックスフックまたは呼び出しバージョン+公開フックであり、現在の古いバージョンのブランチ実装のコードを見て、オプション2を実行し、バージョン+公開を呼び出します（これは誤って最新のタグに公開すると思います）。

解決に関しては、この問題は、フックのリファクタリングとは関係なく、 getLatestReleaseロジックを次のいずれかに置き換えることで解決できる可能性があります。

• （1） listReleasesを使用してgithubリリースをフェッチし、並べ替えて、到達可能な最高のリリースバージョン（プレリリースまたはビルドパーツなし）を見つけます
• （2）またはgitタグをフェッチしてから並べ替えて、到達可能な最高のリリースバージョン（プレリリースまたはビルドパーツなし）を見つけます

ここでの違いは、 autoがgithubリリースまたはgitタグを信頼できる情報源として表示するかどうかです。これは、ディスカッションhttps://github.com/intuit/auto/discussions/1867#discussioncomment-684192に関連してい

私は最初は（2）に傾くでしょう。

• （a）最終的にはgit ref（タグ）の後にあり、githubリリースの他の要素ではありません
• （b）ネットワーク呼び出しの数を減らす

@hipstersmoothie 、
getLatestReleaseロジックを変更する必要がある場合、（1）githubリリースを使用するvs（2）gitタグを使用するvs（3）他の何かについてどう思いますか？

マルチパッケージの自動が機能するには、最新のGitHubリリースのものをすべてタグだけにリファクタリングする必要があります。 2は、この作業を行うためのオプションです。