PRをgit merge --ff-onlyできるようにする

[qryxip]

PRを--ff-onlyの形でマージできる、ラベルで起動するActionを追加します。

動くかどうか試してないのでdraftです。

[qryxip]

参考にしたgh-action-nightly-mergeのドキュメントに気になる一言がありました。

https://github.com/robotology/gh-action-nightly-merge#push_token

Useful for pushing on protected branches.

personal tokenを発行すればbranch protectionを貫通できるということ...?

[sevenc-nanashi]

リポジトリの管理者 or チームにBypass branch protection権限がある人はブランチ保護を無視できたはず…？

[qryxip]

最高の権限があったとしても手元からgit push origin mainしたら怒られたと思うので、それが謎でした。このURLではそうではないということですかね...

[qryxip]

動いたのでdraftを解除します。
qryxip/actions-playground#1

注意点としては、リポジトリのsettingsから次の設定をオンにする必要があるようです (organization下のリポジトリの場合、多分organization側でも設定が必要)。

[Hiroshiba]

fast forwardでマージするの、面白いなと思いました！！！
mainにpushする必要が出てくるのでなかなかむずいし、でも自動半自動化しておきたいしという分野ですねぇ（発想がなかった）

やっぱり権限周りがちょっと危ないかもと思いました！
（それなりに気を配れば大丈夫そうですが）

大対策をいくつか思いつきました！

そもそもgithubにsync fork機能がありそうでした。
（コンフリクト発生時の挙動はちょっと確認してないです）

あと、microsoft/mainをマージするためのbufferブランチ（と勝手に読んでるもの）をPRする手もありそうだなと思いました。
VOICEVOXのブランチ戦略のこちら↓で、release-0.1となっているのがmicrosoft/mainなイメージです。
https://github.com/VOICEVOX/voicevox_project/blob/main/docs/%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%88%A6%E7%95%A5.md#release%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E3%82%92main%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E3%81%AB%E3%83%9E%E3%83%BC%E3%82%B8%E3%81%99%E3%82%8B%E3%81%A8%E3%81%8D%E3%81%AB%E3%82%B3%E3%83%B3%E3%83%95%E3%83%AA%E3%82%AF%E3%83%88%E3%81%8C%E7%99%BA%E7%94%9F%E3%81%99%E3%82%8B%E5%A0%B4%E5%90%88

[Hiroshiba]

あーーー　でもupstreamのmainをマージしたくないんですよね･･･。
upstream側がリリースを切った（いろいろチェックした）ものをマージするのがトラブル防止になると思っています。

sync forkはタグを選んでマージができないのであれば、難しそうかもです。

[qryxip]

sync forkですが、コンフリクト解消の機能は全く無さそうでした。あと対象をタグにできたりもできなさそうです。

またmicrosoft/onnxruntimeの状況ですが、microsoft#12606以降Rustバインディングが一切更新が無く放置されており、正式なリリースがされるのはまだ先と見てよいと思います。そのためこのリポジトリではしばらくの間、

• relブランチでタグ(e.g. v.1.14.1)をベースにlibonnxruntimeの改造を行い
• mainブランチでmainをベースに新生onnxruntime-rsの改造を行う

ということをすることになるのかなと思っています。

[Hiroshiba]

relブランチでタグ(e.g. v.1.14.1)をベースにlibonnxruntimeの改造を行い
mainブランチでmainをベースに新生onnxruntime-rsの改造を行う

良さそうに思いました！
頂いたこちらのPRはどうしましょう･･･？

[Hiroshiba]

個人的には、本家mainを取り込みたいときは、本家のbranchをこちらにプルリク作成するのもありかなと思いました。
取り込む頻度が少なそうで、運用ルールをまとめるほうが大変な気がするなぁと。

でもせっかく作っていただいたので、取り込みたい気持ちもあります。
なので、めちゃくちゃ雑でもいいので起動方法メモをREADMEを書き足すとかどうでしょう。
今のREADMEの上に VOICEVOX onnxruntimeみたいな項目を設けて雑にこのworkflowの使い方を紹介する項目を追加し、その下を---で区切って本家READMEを続ける感じを考えてます。

[qryxip]

思ったのですが、PRのテンプレートにも以下のようなものを付けた方がいいのかなと。

<!-- ラベル`ff-merge`を付けると、ワークフロー`FF merge`が作動して`--ff-only`のマージが行われる。 --->
- [ ] 本PRは`--ff-only`でマージする。GitHubのUIでマージされるべきではない

(なんかうっかり普通にマージしちゃいそうなんですよね...)

[Hiroshiba]

たしかに！

[Hiroshiba]

READMEじゃなくてworkflowのymlファイルの一番上での説明とかでも良いかもです。
どちらでも！

[qryxip]

workflow fileにコメントとして書きました。

あとこれもpull request templateに追加しました。
#1 (comment)

[qryxip]

@y-chan すみません。このPRですがSHAREVOXで同じことができないかと思っています。どうでしょうか?

「upstreamのマージ」を行う機会が多いSHAREVOXで扱いやすいような形が、このVOICEVOX/onnxruntimeにも適しているんじゃないかと思っています。

とりあえずこのPRのアプローチのデメリットとしては

• branch protectionを切る必要がある

あたりでしょうか。代替としては手元でBashスクリプトを動かすのが挙げられると思います。
(追記) いや手元のBashでも、多分personal tokenは発行しないとbranch protectionは突破できませんね... 微妙かも

[y-chan]

すみません...!ちょっと意図が掴めてないのですが、SHAREVOX側でVOICEVOX側の変更をマージする形で、このActionの運用を試してみるって感じですかね...?
私は大丈夫なので、PRだけ作ってもらえると助かるかなと...!(違うのであればごめんなさい)

[qryxip]

はい、そうです。

このアプローチ自体にbranch protectionを切る必要がある等のデメリットがあるため、SHAREVOXとしてそもそも興味があるか&デメリットが飲めるかの確認がまずしたかったです(すみません、言葉が足りてませんでした…)。

大丈夫なのであればPRを作らせていただきます…!

[qryxip]

@Hiroshiba すみません、このPRは一旦draftでいいでしょうか...? (このリポジトリでのff-mergeの出番は多分しばらく無いので)

[Hiroshiba]

もちろん大丈夫です！！

[Hiroshiba]

課題を思いついたのでメモです。

actions/checkout@v3は通常depth=1でcloneをします。
なのでff-onlyでマージしても、コンフリクトしているかどうかのチェックはできていないかもしれません。
depth=0でcheckoutすると大丈夫ですがonnxruntimeが凄まじい履歴を持っているのでちょっと大変かも。