-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PDF版の自動更新 #241
Comments
@y-yu PDF版の更新、いつもありがとうございます。 Circle CI ですが、調べてみたところ、follow という概念しかなく、管理者という概念はないようです。(y-yu さんは、すでに Circle CI 上の the-rust-programming-language-ja を follow されているようです。リンク) Circle CI から GitHub のレポジトリに SSH キーや web hook を登録する際は、GitHub リポジトリ側の管理者権限が必要になります(参考)。そこで、trpl-admin という管理者チームを作って、y-yu さんを登録しました。
Circle CI に登録された SSH 秘密鍵の一覧(fingerprint のみ表示)は、こちらにあります。 現状は、github.com 向けのものだけが登録されています。この鍵は私が管理してますので、公開鍵を教えることはできます。ただ、今回連携したい先は、GitHub ではなくて、Travis でしょうか? だとすると、新たに、Travis 向けのキーを作成して、登録することになるのかもしれません。(よく分かってなくて、すみません。) |
Circle CI メモ: |
公開鍵ですが、こちらに置きました。 finderprint:
|
@tatsuya6502 さん。 trpl-ja-pdf にいただいた公開鍵を登録しようとしたのですが、次のようなエラーが出てしまってだめのようにです。
つまり、GitHubはあるリポジトリにデプロイキーとして登録されている公開鍵を別のリポジトリのデプロイキーとして登録できないようです。 |
GitHub の別のリポジトリでしたか。 Circle CI の web API を使うと、CI から別の CI を起動できるようです(参考)。ということは、もし、Circle CI に trpl-ja-pdf の CI を作成したなら、そこに登録したそれ専用のデプロイキー(trpl-ja で使っているものとは別のもの)を使って GitHub trpl-ja-pdf に連携できそうです。 流れ:
|
ちょっと試していないので確実ではないですが、実はtrpl-ja-pdfはtrpl-jaリポジトリをサブモジュールで管理していますので、その関係でCIがややこしい(何度も実行されたりする)ことになりそうな予感がします。 方法
という手順でいってはどうかと思います。けっこう強引な方法なのですが、どうでしょうか。 参考 |
@y-yu さんの案(trpl-ja の CI の途中で deploy key を入れ替えて、trpl-ja から trpl-ja-pdf へ自動コミットする)も、たしかに動くと思います。しかし、これは最後の手段としてとっておいて、この自動コミットは、trpl-ja-pdf の CI で行わせた方がよさそうに感じます。 理由は、trpl-ja の CI と trpl-ja-pdf の CI をできる限り疎結合にしたいからです。そうすることで以下のような利点があります。
また、別の理由として、この仕組みが壊れやすそうなこともあります。
もう少し調べたところ、Travis CI でも web API 経由で CI を起動できることがわかりました。 そこで、trpl-ja の CI は、この API を経由して、trpl-ja-pdf の既存の Travis CI による CI を起動するだけにして、残り、というか、メインの作業、つまり、サブモジュールの更新と trpl-ja-pdf への自動コミットは trpl-ja-pdf の既存の CI に行わせてはどうでしょうか? そこでは、すでに deploy key がセットアップされていて、gh-pages ブランチへの自動コミットを行っていますので、少ない修正で実現できそうです。 自動コミットにより CI が何度も実行されてしまう問題については、自動コミットのメッセージに 流れ
ステップ 4.1 は、trpl-ja の自動コミットのスクリプトが参考になるかもしれません。コミットするものがあるときだけ、コミットするしくみになっています。 |
メモ: trpl-ja の最新版を pull する前に、/1.9/ja/book に変更があるかを確認するコマンド。
結果が |
この方法で構わなければ、私の方で実装してみようと思います。ちょっと時間がかかるかもしれませんが、完成したら、trpl-ja-pdf と trpl-ja に、順に pull request を上げます。
|
うーん、ちょっと見てみないとわからないのですが、trpl-ja-pdfのCIの挙動が次のような二つになりそうな予感がします。
すると、条件文を次のように書くことになる気がします。
こんな感じになるでしょうか。(ちょっと複雑で、僕もうまく状況が掴めていないかもしれないので、確認させてほしいと思います) |
説明不足ですみません。
例: trpl-ja の Circle CI によりキックされた場合
trpl-ja-pdf の master 更新によりキックされた場合
この方法の利点は、PDF のビルドに成功しない限り、trpl-ja-pdf の master ブランチの submodule が更新されないことです。もし trpl-ja でなにか breaking な変更(例えば /1.9/ja/book のデレクトリ構造を /1.9/book に変更した)があって、そのままでは PDF のビルドが通らなくなったとしたら。そういう場合は、trpl-ja-pdf の master ブランチの submodule は、PDF のビルドが通るリビジョンがキープされます。 もう少し複雑な判断をさせたい場合trpl-ja-pdf は trpl-ja の /1.9/ja/book ディレクトリの内容だけに依存しています。そこに変更があったときだけ、submodule を更新することもできます。 この場合は、Circle CI によって起動されたかどうかも判断したほうがよさそうです。Travis CI の API をコールする際に、任意の環境変数を設定できますので、それで判断しましょう。仮にその環境変数を、TRPL_JA_NEW_COMMIT とします。
|
なるほど。詳細な説明をありがとうございます。これでよさそうに感じました。複雑な方法はとりあえずは使わずに、trpl-jaの方に変更があれば常にtrpl-ja-pdfを更新するという方針でよいと思います。
もし、お忙しいようでしたら引き継ぎますので、気軽におねがいします。 |
納得していただけたようで、よかったです。
了解です。これで進めますね。 |
@tatsuya6502 さん。 この件ですが、お忙しいようでしたら私の方でやってみましょうか? |
本日、作業してます。お待たせして本当にすみません。 |
|
PR #278 をオープンしました。 |
こちらのリポジトリでCIが動作して成功した場合、PDF版を自動で更新したいと思っています(現在は私が適当なタイミングで手動により更新しています)。そのため、Circle CIの管理者に追加していただくか、すでにCircle CIに秘密鍵が登録されている場合はその公開鍵を教えていただきたいと思います。
The text was updated successfully, but these errors were encountered: