サクラエディタのデイリービルドを GitHub Release にアップできないか検討する

[m-tmatma]

#481 で @jakenjarvis さんから 成果物を残す要望が上がっている

GitHub Release に正式版をあげるつもりではあるが、手動でアップすることを想定していた。

https://github.com/sakura-editor/sakura/releases にあげるのを検討する前に
実験もかねて appveyor から自動的に、https://github.com/sakura-editor/sakura
とは別にデイリービルドのアップ用のリポジトリを用意してそちらにアップロードしてみる。

他プロジェクトの例

役割	URL
メインリポジトリ	https://github.com/universal-ctags/ctags
デイリービルド用	https://github.com/universal-ctags/ctags-win32/releases

[m-tmatma]

https://github.com/jakenjarvis/PreventReboot/blob/master/appveyor.yml
にある appveyor deploy GitHub をキーワードに検索すると

• https://www.appveyor.com/docs/deployment/github/
• https://qiita.com/ueokande/items/eb5fed3c68c957a4b89e
• http://final.hateblo.jp/entry/2015/09/27/113241

などが見つかる

[m-tmatma]

universal-ctags では https://github.com/universal-ctags/ctags ではなく
https://github.com/universal-ctags/ctags-win32 側の appveyor.yml で Release にあげている模様。

https://github.com/universal-ctags/ctags-win32/blob/db8b66453d38630b0bf6b5a77a42dd655f743073/appveyor.yml#L39-L56

[k-takata]

ctags-win32 は、AppVeyor のサポートに cron を許可してもらって、1日1回 ctags をチェックし、更新があれば更新内容を gitlog.txt に書き込みます。それをコミットしてタグを付けて ctags-win32 にプッシュするともう1回 CI が走るので、ビルドをして ctags-win32 の Releases にアップロードします。（タグのビルドかどうかで処理を分けています。）

元々これは、vim/vim-win32-installer で作った仕組みで、cron を走らせるシステムと、ビルドをするシステムは分けていたので、このような2段階になっていますが、本当は分ける必要はないはずです。

あと、GitHub Releasesにアップロードする際に使っているアクセストークンは専用アカウントを1つ用意しています。というのは、アクセストークンはアカウントに属するものなので、悪用されると同じアカウントの他のリポジトリに影響が出る可能性を危惧したからです。もっとも、アクセストークンは暗号化しているので、悪用されうるのは、同じリポジトリに書き込みできる誰かが悪意を持ったコミットを行った場合に限られるはずですが。

[k-takata]

sakuraのデイリービルドリポジトリを用意し、正式タグ有りのビルドの場合はsakura本体のリポジトリにアップロードするというのは有りでしょうね。
以前にも書いたように、prereleaseでアップロードしておき、最終チェックとリリースノートが書き終わったら、正式リリースに変更するという運用が考えられます。

[k-takata]

prereleaseでアップロードしておき、

draftの方がいいかも。draftだと、権限のある人しか見れません。
そういえば、ビルドしたリポジトリと別リポジトリにreleasesをアップロードってできるのだろうか？

https://www.appveyor.com/docs/deployment/github/#provider-settings
repository でアップロード先のリポジトリは指定できるようだが、場合分けは無理？

[jakenjarvis]

他のリポジトリを見てると、Deployする流れは主に３パターンあるみたいです。

① gitでtagを手動で付けて、AppVeyorにはそれを見て動いてもらう方法。
② 特定のブランチにPushされたらAppVeyorにtag付けさせて動く方法。
③ k-takata さんが書いた cronでリポジトリ監視させて動く方法。

「発行するバージョンをどこで管理（決定）するか」や「デプロイタイミング」で、これらを使い分ける感じだと思います。

※結局どれもgitでtag付けが必要になるので、私は①が一番シンプルになると考えてます。（実際、②と③をやるとなると、appveyor.ymlの記載が多くなり、appveyor.ymlのテストも面倒です）

---

ビルドしたリポジトリと別リポジトリにreleasesをアップロードってできるのだろうか？

できるはずです。Personal access tokensの登録画面には、「どこからUPされるか」についての登録はありません。そのため、その正しいトークンが使われれば、どこからでもUPできると思います。
また、UPするリポジトリが異なっても、以下のようにproviderを複数記載して、それぞれ別の設定を書けばいいだけだと思います。

deploy:
  - provider: GitHub
      (省略) sakura本体のリポジトリ
  - provider: GitHub
      (省略) デイリービルドのリポジトリ

このあたりも参照ください。GitHub ReleasesとBinTrayの例を挙げてますが、２か所の異なるGitHub Releasesが対象の場合も同じです。（長文セット！）
#481 (comment)
#189 (comment)
#481 (comment)

ところで、正式ビルドをGitHub Releasesにするのは、私も同意です。ですが、正式ビルド以外（デイリービルド等）までGitHub Releasesにこだわっている理由は何かあるんでしょうか？
BinTray提案したけど、反応ないよ～（泣）

[berryzplus]

Dailyビルドが必要なほど更新されていないので一旦閉じてしまいます。

個人的な感覚では、1週間あたり2PRくらいマージされていく状況でなければDailyビルドは不要だと思います。