vuejs/vuejs.org との差分を同期する仕組み

[kazupon]

従来、vuejs/jp.vuejs.org でやっていた本家のドキュメント差分内容を取り組み仕組みが必要。

MEMO

現時点でこのrepoに取り込まれた本家の最新のコミットハッシュ
032c9d5

[potato4d]

これ che-tsumi 方式から本家と同期していく方向で変えて行きたくて、ちょっとオピニオンがあるので10/4までボールもたせてほしいのですが、それまでにできそうになかったら誰かにやってもらいたい気持ちがあります

[kazupon]

@bencodezen
We might ask the vue.js docs team for support to keep the documentation content up to date in vuejs/vuejs.org (vuejs/docs-next). 🙏

We will contact you when we have decided on our requirements.

[kazupon]

@potato4d
了解です。同期の仕組みの内容 (仕様) が決まったら、他の人、もしくは自分がやります。

[kazupon]

@potato4d
もう10/4過ぎてしまってあれですが、

これ che-tsumi 方式から本家と同期していく方向で変えて行きたくて

これ、持っているアイデア、どういう方式か教えてもらえます？ 🙏

[potato4d]

もう10/4過ぎてしまってあれですが、

こちら手をつけられておらずすみません 🙇‍♂️
イメージについての説明の図作りますね

[potato4d]

図で表すほどではなかった……

GitHub Actions ベースでの翻訳の upstream 追従について

とりあえず現実的な案として 2 つ。あとは既にあるソリューションを共有します。

原則

• コンピューティングリソースは CI 以外使いたくない

他のリソースを使うと誰かが管理する必要が出てくるので、コミュニティとしては管理の冗長性を最大化しておきたいため

実装案

A. 翻訳側が定期的に実行する

現行に近い動作をしつつ、サーバー依存を最小限にする形式。

1. GitHub Actions の cron によって毎日定時にバッチを実行する
2. 実行するバッチでは、environment variables で指定した origin repo の最新のコミット一覧を取得する
3. まだ取り込まれていないものがあればそれを取り込もうとする
4. 成功したら Pull Request を、失敗したら Issue を作成する
5. environment variables で指定した user を reviewer/assigneeに設定する

Pros

• vuejs-jp/sharin が行っている形式に近く、コンピューティングリソースを利用しない
  • Heroku などでメンテナンスが不要
• GitHub Actions についている GITHUB_TOKEN を取り回せるので、 Bot User が不要
• 翻訳(fork)側が勝手に実行できる
• Custom Action をつくることができれば、 Vue.js 以外の翻訳でも利用できそう

Cons

• もし一日に大量のコミットが発生した場合は取りこぼす可能性がありそう？
  • 多分 vuejs-jp/sharin の現行実装は24時間で21個以上のコミットがあると取りこぼす
• (基本的にはないが)急いで何かを取り込みたいという場合に対応しきれない

B. upstream が master への commit を契機に fork に通知する

確実に実行を担保し、アーキテクチャ的には綺麗だがコストが高そうな方法

upstream

1. vuejs/docs-next の commit を契機に CI を実行する
2. environment variables で指定した fork 一覧に対して、それぞれ update 用の Action を commit hash つきで dispatch する(あるいは commit の title と hash がついた Issue を発行する)

fork

1. upstream から受け取った情報をもとに、origin にたいしてそのコミットを cheery-pick し、それを取り込もうとする
2. 成功したら Pull Request を、失敗したら Issue を作成する
3. environment variables で指定した user を reviewer/assigneeに設定する

Pros

• 構造としてはキレイなほか、リアルタイム性や取りこぼしの観点でも信頼性は高い
• Custom Action をつくることができれば、 Vue.js 以外の翻訳でも利用できそう

Cons

• 本家に対して処理が挟まるのでカロリーは高い気がする

C. 既存資産 che-tsumi or sharin の利用

• この辺りはやらずに単純にこれまで通り運用する

その他検討事項

実行ランタイム

GitHub Actions には Shell と Docker があり、実行するランタイムを選択できる。

実行速度の面では Shell にかなり分があるが、利用体験としては Docker 上で Node.js 環境を動かすほうが快適に思える。

A 方式を利用する場合はそもそも定時バッチなのであまり気にならない。B/Cは遅延が気になることがあるかもしれない、Cの場合は親側の実行時間が枯渇しないかが気になる。

Custom Action としての切り出し

やりたいことは翻訳に限らずforkがupstreamを素早く追従できる仕組みなので、できれば Custom Action として切り出したい。

ただ作業コスト・メンテナンスコストはもちろんあるので、まずは vuejs-jp でやってしまってからで良いと思う。

(正直他の言語の翻訳でも転用してもらいたく、ここを一番やりたい)

[kazupon]

ありがとうございます！

Cの場合は親側の実行時間が枯渇しないかが気になる。

これ、C ではなく、B ですよね？

environment variables で指定した fork 一覧に対して、それぞれ update 用の Action を commit hash つきで dispatch する(あるいは commit の title と hash がついた Issue を発行する)

Bのこういった、親(upstream) が子 (fork先) に対して何らかの処理をしているので。

個人的には B を採用したいですね。
ただ、vuejs.org の方、自分が認識している範囲では、github actions のリソースはそんなに使っていないという認識ですが、使っているかもしれないので、ちょっと確認が必要かも。

やりたいことは翻訳に限らずforkがupstreamを素早く追従できる仕組みなので、できれば Custom Action として切り出したい。

翻訳だけでなく、fork した OSS にも使えると思うので、ぜひ、Custom Actions として切り出したいですね！

ただ作業コスト・メンテナンスコストはもちろんあるので、まずは vuejs-jp でやってしまってからで良いと思う。
(正直他の言語の翻訳でも転用してもらいたく、ここを一番やりたい)

agree です。
doc-next に毎日 PR が来ているほどでもないので、今のところ、急いでいるわけではないので、大丈夫です。

[potato4d]

@kazupon

これ、C ではなく、B ですよね？
すみません、Bです 🙇

Bを採用したいですよね。ちょっとリソース面どうであるか確認いただけますと幸いです！

[kazupon]

今日の翻訳グループのMTGで一旦 che-tsumi 方式で行くことにした。
che-tsumi 方式、GitHub Actions で動作するか等の検証して、問題なければそれで対応していく。

[kiaking]

本件、Che-TsumiをGitHub Actionsに対応させるため、 Che Tsumi Nextを作成しました。

Cherry Pickする方法など、ベースの部分はほぼ同じなのですが、定期実行の仕組みがGitHub Actionsの定期実行になるので、現状のChe TsumiのFeedEmitterで更新検知する必要がないなど、割と実装がことなるので、別に作っている感じです。また、どこまで差分をチェックしたかも、GitHubのWorkflowの履歴から取ってくるようになってます。

今のChe Tsumiはスタンドアローンでホストする場合に便利だと思うので、そのままにし、GitHub Actions用は分岐させるのが良いかなと思ってます。

本件、Vueコアチーム側でも話を進めており、他のコミュニティへの展開なども視野に入れてる状況です。最終的に、このレポジトリも含め、「公式」の翻訳関係のレポをどう管理していくか、別途コアチーム側でサジェストがありそうです。

例えば中国語の翻訳レポジトリがvuejs配下に置かれて、日本語がvuejs-jp配下だと「公式」のプロジェクトだと思われない可能性とかもあると思うので、できるだけ統一する方がいいかなと思ってます。

その上で、Che Tsumiの扱いなども吟味する必要がありそう（誰がメンテするのか？ どこに置くのか？）。

またちょっと確認して連絡します！

[kazupon]

@kiaking
ありがとうございます！
引き続き、よろしくお願いします！