ワークフローを組み直そう

[Enchan]

何がどうなってるのかもうわけわからんことになってる()

[Enchan]

一旦ワークフロー消して、バージョンをPyPI準拠に合わせて各ブランチにpushします

[Enchan]

一旦ドキュメントソースも消します
(gh-pagesブランチでやりくりします)

[Enchan]

docsをgitignoreして、ワークフローん中でビルド+生成+コミットまでやればいい…のかな?
もしかすっとコミットすらする必要ないかもしれないね

[Enchan]

おけおけ
一旦マージしてワークフローの暴走を止めよう

[Enchan]

ユニットテストワークフローを追加

パッケージとしてインストールしないと単体テストができないのはどう考えても何かがおかしいのでここは要修正(sys.pathをいじるだけでいいはずなんだけどなんでそうしないかは謎)

[Enchan]

apidocなんてあったわねえ…

[Enchan]

ドキュメントビルドワークフローを追加

apidocも多分これで問題なく動くと思う

[Enchan]

sphinx-multiversionさん！！？！？

[Enchan]

あーそうかビルド時に他のブランチの存在見えてないのか(checkoutの仕様的に他のブランチはcloneされない?)…

[Enchan]

peaceiris/actions-gh-pages の仕様的に、それまで存在したファイルがリプレースされるらしいので…

そのあたりを自前で作る必要があるわけか

[Enchan]

ホームメイドは草

[Enchan]

修正

[Enchan]

え、きたんじゃね? 一旦やってみるか

[Enchan]

忘れてた…

[Enchan]

一旦pullしないとダメかな?

[Enchan]

mv、デフォルトで置き換えないのかこいつ…

まてよそうなるとdeletion検知できなくなるな??

[Enchan]

deletionを検知するには…

やはり一旦rm -rfするのが一番では…?

[Enchan]

一旦消して移動して、gitからはadd/delがあったように見せかける作戦!

[Enchan]

いやまて変更なかったときcommitに失敗するぞこれ

[Enchan]

ありえる…よな 全く同じ内容で実行すれば同じ内容が返るはず…

うーん

[Enchan]

シェルってマジでなんでもできるな…()

[Enchan]

自動でリリースブランチに飛ぶように あとはバージョン切り替えをどうするかだ

[Enchan]

自動バージョニングも考えないとね

[Enchan]

次期リリースバージョン番号を算出するスクリプトを別で持たせたほうがいい気がするのですよねぇ…

でもコミットスタイル的に自動算出はかなり難しそう.

[Enchan]

FROM="HEAD"
TO="V2.0.6" # previous version

git log $FROM...$TO | grep "^    \[" | gsed -e 's/^    //' | cut -c 2-40 | uniq | gsed -r 's/^(.+?)\].*$/\1/'

を実行することで

Update #85
Modify #85
Update #85
Modify #85
Modify #85
Add #85
Add #85
Update #85
Modify #85
Delete #85
......

こんな感じで拾えるので、これを何かに使えないだろうか

[Enchan]

とりあえず

• リポジトリ内のバージョンに関する記述を集約管理し、sedで置換するシェルスクリプト
• 指定したバージョンへ更新し、git commit してくれるシェルスクリプト

があれば 手動更新も自動更新も対応できそう.
アップデート時のコミットメッセージを [Release] v2.0.6...v3.0.0 みたいな感じにすれば、リリースワークフローの前に「自動バージョニングを行うべきか」を判定できる…のか?

[Enchan]

問題は「自動リリースをいつ行うか」という点.
Releaseブランチへのmerge時と仮定すると、ブランチにmergeされた際に「[Release]で指定されたコミットが前バージョンとHEADの間にあれば 手動バージョニングが行われたと判定し、そうでなければ例のスクリプトから算出する」みたいな感じにするか

そうなるとどのみち次期バージョンを算出するシェルを描くことになりますね

[Enchan]

ci/*.shを作るか…

[Enchan]

(正直どこでも使えるスクリプトになりそうなので、これとは完全に別のところで作るのもいいと思います)

[Enchan]

とりあえずvercalc.shを作ってルートに置いておくので、グローバルで使えるようにするかどうかは後で考えましょう

[Enchan]

% ./vercalc.sh | tail -n 20
Analyse commit history from v2.0.6 -> HEAD ...
Commits: 30
Breakdown:
    Add         2
    Update      10
    Modify      14
    Delete      2
    Fix         2
Calculate version increments...
Recommended new version:
v2.1.0

めっちゃいい感じ

[Enchan]

ちゃんとttyかどうか判断して色付けします サイコー

[Enchan]

Makefileもいらないよね(誤解を招くだけ

[Enchan]

あとはバージョニングスクリプトだ

[Enchan]

今のところバージョン情報が書いてあるのは

• setup.cfg
• src.blueprintpy.core.version
• docs/source/conf.py importで読むよう修正

[Enchan]

.versioning_patterns.shみたいなのを作って管理するか、versioning.shで一元的にやるか

[Enchan]

二つしかいじるファイルなかったのでversioning.shでまとめました
(CSV読んで置換とかやりたかったけど無理)

[Enchan]

破壊的変更がないので一旦メインブランチにmergeして、新しいissueを立てよう