search

sakura-editor / management-forum

管理・運用向けフォーラム（Issues をフォーラム代わりに使う）
2 stars 0 forks source link

変更履歴の作成に関して検討する #53

Closed m-tmatma closed 5 years ago

m-tmatma commented 5 years ago

変更履歴の作成に関して検討する

m-tmatma commented 5 years ago

前回のリリースからの変更差分は https://github.com/sakura-editor/sakura/milestone/1 を見ればわかるようになっている。

しかし、手動で作成するのはめんどくさい。なんとか自動化したい。

ChangeLog GitHub auto とかで検索したら以下を見つけた。 https://github.com/github-changelog-generator/github-changelog-generator

あと、GitHub API python とかで検索したら以下を見つけた。 https://github.com/PyGithub/PyGithub/blob/master/README.md

前者は多分全部自動でやってくれるもの、後者は GitHub API を駆使して自分でやる方法。

m-tmatma commented 5 years ago

ちょっと古いが、いろんなツールをまとめているサイト https://efcl.info/2014/07/20/git-tag-to-release-github/

m-tmatma commented 5 years ago

ChangeLog GitHub auto とかで検索したら以下を見つけた。 https://github.com/github-changelog-generator/github-changelog-generator

実際に使った人の話。

KENCHjp commented 5 years ago

そうですね。正確さより省力化に趣を置きたい気がしています。 tagで「BUG」と「エンハンス」がついてるコミットを羅列するぐらいを目指したいですね。

berryzplus commented 5 years ago

ある意味自由にやっていただいて構わんです。

一発目なので「こんな感じでやれると思う」を確かめることが大事だと思います。この先ずっとこれでやりますとやってみますじゃレビュー時のハードルの高さは違ってきます。

まずは無理なくやりたいので、好きなようにやってみるで進めてはどうでしょうか。

あんまり外れたやり方したら、きっと k_takata さんが突っ込んでくれますし。(人任せ

takke commented 5 years ago

興味があったので github-changelog-generator で CHANGELOG.md を作ってみました。

https://gist.github.com/takke/1ddc5b6e6c52c9462be38994c911fb3c

ひとまず網羅的に PR や Issue を拾えていると思うのでここから exclude-labels を使って「CHANGELOG.md に含めたくない PR や Issue」をマークしていくといいのではないでしょうか。

試しに「CI」ラベルのものを除去したのがこちらです。

https://gist.github.com/takke/4641ce2fa7d66015f56bc21957cd8dd1

ローカルのLinuxマシンで実行すると数分程度かかりましたが、AppVeyor 等のCIでも実行はできそうです。

takke commented 5 years ago

AppVeyor でも実行できました。

KENCHjp commented 5 years ago

@takke さん、色々と調査報告ありがとうございます。 活用させていただきます！

m-tmatma commented 5 years ago

AppVeyor でも実行できました。

* AppVeyor の Settings -> Environment で Environment variables に `CHANGELOG_GITHUB_TOKEN` を追加しておく。public_repo のみ許可したトークンで OK

現状、developer と admin が存在しますが、 読み取り専用の権限を持つ readonly の新しい team を新設して専用のアカウントを 追加するのを考えています。

理由は、GitHub API にそれなりの頻度でアクセスするためには、token を使用する必要がありますが、 developer と admin に属している人のアカウントで作成した token の場合には、必要のない書き込み 権限がついているかもしれないからです。

正しく設定すれば不要な権限がつかないのかもしれませんが、設定を間違った上で生成した token が 漏れた場合の影響を最小限にするために、読み取りしか必要のないので権限を最小限にしたいからです。

KENCHjp commented 5 years ago

読み取りしか必要のないので権限を最小限にしたいからです。

イイと思います。

KENCHjp commented 5 years ago

とりあえず、CloseのPRでラベルがついてない（特にCIとmanagement、refactoring。ようは、機能エンハンスではないものをより分けたい為）ものに一通りLabelつけてみました。

takke commented 5 years ago

再生成しておきました https://gist.github.com/takke/68e44912a4358e17c315699434486ea5

takke commented 5 years ago

https://github.com/sakura-editor/changelog のような感じで github_changelog_generator 用のリポジトリを作って AppVeyor と連動、自動生成させてみてはいかがでしょう。

sakura-editor/sakura/appveyor.yml の after_build: に組み込んで、sakura-editor/sakura へのコミットのたびに CHANGELOG.md が作られ、自動コミットされるようにもできますが、頻繁すぎてコミットログが汚れますよね。

むしろchangelog生成専用リポジトリを作っておいて、サクラエディタの正式リリースのときに専用リポジトリから持ってきてコミットする(あるいは URL だけ書いておく)運用でいいんじゃないかと思います。

外野から失礼しました。

m-tmatma commented 5 years ago

appeyor で生成するのは、ビルド時間がさらに長くなるのでどうしようか思案中です。

毎回生成する必要はないので、 APPVEYOR_FORCED_BUILD の環境変数が設定されているときだけに 限定するのでもいいのかも。

berryzplus commented 5 years ago

むしろchangelog生成専用リポジトリを作っておいて、サクラエディタの正式リリースのときに専用リポジトリから持ってきてコミットする(あるいは URL だけ書いておく)運用でいいんじゃないかと思います。

これやってもいいように思います。

毎回リリース用に新規で作るのか、今回だけにするのかは後で考えるとして、 sakura-editor/changelog を作ってみてはどうでしょうか。 異なるリポジトリでやればビルド時間には影響しないはず・・・。

リポジトリの名前にこだわるかどうかは任せます（笑

m-tmatma commented 5 years ago

異なるリポジトリでやればビルド時間には影響しないはず・・・

appveyor のインスタンスはアカウント単位で一つなので sakura-editor の organizaion 内の 別のリポジトリでビルドされていると、sakura 側のリポジトリのビルドが待たされます。

m-tmatma commented 5 years ago

異なるリポジトリでやればビルド時間には影響しないはず・・・

appveyor のインスタンスはアカウント単位で一つなので sakura-editor の organizaion 内の 別のリポジトリでビルドされていると、sakura 側のリポジトリのビルドが待たされます。

appveyor のサポートに依頼する必要がありますが、

sakura-editor/changelog に対して、定期実行の機能を有効にしてもらって(標準では無効化されている)、夜中に一日一回実行するとかにすればいいかも。

sakura-editor/changelog の artifacts として ChangeLog をダウンロードできるようにしておけばいい。 appveyor に対して、手動で sakura-editor/changelog に対してビルドすれば、いつでもその時点での最新の ChangeLog を生成できる。

普段は sakura-editor/changelog に対して commit が入らないので、定期実行以外では ビルドが走らないので、sakura 側のビルド時間を専有することもない。

その上で適当なタイミングで sakura-editor/sakura に手動でコミットすれば良さそう。

m-tmatma commented 5 years ago

sakura-editor/changelog → sakura-editor/changelog-sakura みたいな名前にしようと思います。

理由は 単に changelog だと、もし他のプロジェクトでもこの仕組みを参考にして広く使われる ようになった場合に複数のプロジェクトに貢献したい人(私も含む)が、複数の fork を作るときに changelog の名前がかぶってしまうからです。

takke commented 5 years ago

私が検証した内容を切り出して changelog-sakura を作っておきました。

https://github.com/takke/changelog-sakura

m-tmatma commented 5 years ago

https://github.com/sakura-editor/changelog-sakura/pull/1 で対応できました。

結構時間かかった。

beru commented 5 years ago

変更履歴の区分に

とありますが enhancement でも bug でも無い Closed issues は含めないでも良いのではないかと思います。理由としては認識間違いで何も対処する必要が無かったので閉じたものとか、課題としては挙げたけれど対処はせずにCloseしたものとかも含まれるからです。

マージされたPRの列挙だけだと変更履歴としては分かりにくくて不十分になってしまうんですかね。。

KENCHjp commented 5 years ago

マージされたPRの列挙だけだと変更履歴としては分かりにくくて不十分になってしまうんですかね。。

とりあえずPRだけでいいとおもうんですが、リファクタリング（フォルダ構成変更なども含む）とかインストーラーとか、mdだけ修正とかもあるので、PRのBugとenhancementsを対象で、CIとかmanagementとかを除外すればそれなりのができるかなと。

takke commented 5 years ago

Closed issues は私も余計かなーと感じていました。「Issue を上げて PR で修正」という流れだと2重にChangeLog の項目が上がってしまうので。

github-changelog-generator のオプション を調べてみるとそのものズバリの [no-]issues および [no-]issues-wo-labels があります。が、結論から言うと使えませんでした。

--no-issues-wo-labels はgithub-changelog-generator のバグで動作しません。(時間かけて4パターン試したのに、まさかバグとは･･･)

また、--no-issues で Issue を除外すると、enhancements/bugs の分類がなくなり、Merged pull requests: のみになりました。

上記バグの workaround には「exclude-labels=no-changelog のように no-changelog ラベルを付ける」方法が紹介されていますし、ちょっと手間ですが「Issuesにはno-changelogラベルを付ける」が確実かと思います。

KENCHjp commented 5 years ago

抜き出した後に「手動」が入ってもいいかなと思います。 もしくは放置（許容）。 工数とのバーターですが、OSSなのでできうる範囲の最前解をとるのも手かと。

takke commented 5 years ago

max-issues というオプションもあったので 0 を指定してみましたがなんと Issues を 100 件取得しました(gem本体のソースも見てみましたが取得するページ数という動きになっていました)。 一応生成結果を置いておきます: https://github.com/takke/changelog-sakura-sample/blob/75304c169ab08b9df65c12d978d4c3d7836a7698/CHANGELOG.md

m-tmatma commented 5 years ago

この件に関して何かあれば https://github.com/sakura-editor/changelog-sakura/issues にお願いします。