同じソースツリーでテストが通っていたらテストをスキップする | おそらくはそれさえも平凡な日々

tl;dr git rev-parse HEAD^{tree} でツリーオブジェクトのハッシュ値が取れるので、ブランチが異なる場合でも同じソースツリーであるかどうかを判定できます。 これを利用して、すでにテストを通ったtreeのハッシュ値をどこかに記録しておいて、同一のソースツリーに対するテストをスキップできます。 本題 よく使われている、develop/mainブランチ運用をしている場合に、ちょっとした修正を本番に入れたい場合には以下のようなフローを踏むことになるでしょう。 featureブランチをdevelopブランチの先頭から切って修正を作ってテストが通るのを待つ developブランチにfeatureブランチにマージしてテストが通るのを待つ mainブランチにdevelopブランチをマージしてテストが通ったらdeployする さて、この時、他の作業が混ざらない限りにおいては1,2,

[Songmu]

blogged.

[sue445]

CircleCIだとキャッシュのキーを上書きできないのでS3使ってるのか。GitLab CIならキーを上書きできるのでCIのキャッシュを使ってもいいかもしれない

[sinsoku]

git rev-parse @^1^{tree} と git rev-parse @^2^{tree} で比較すればs3要らないかも

[kiririmode]

テストpass時のリポジトリ全体のtree hashをS3に保存しておき、同一ハッシュの場合はテストをスキップする仕組み

[castaneai]

“git rev-parse HEAD^{tree} でツリーオブジェクトのハッシュ値が取れるので、ブランチが異なる場合でも同じソースツリーであるかどうかを判定できます。”

[ngyuki]

CIでビルド的なことしていると同様に別のビルドがデプロイされてしまう問題があるのでツリーのハッシュをキーにしたアーティファクトを保持するなどしてどうにかしたい

[hitode909]

よさそう、やりたい

[tettekete37564]

“git rev-parse HEAD^{tree} でツリーオブジェクトのハッシュ値が取れる” < へぇーへぇー

[gg119104]

nrwl/nx って似たようなことができるモノレポ管理ツールがあるよ、今はまだテッキーだけど結構期待してる

[daikikohara]

指定したパスに変更がなければだったらもっと簡単だけどダメなのかな。テスト結果も考慮するんだと確かに何らかのストレージは必要な気はする。overkill感はあるけどTTL設定しておけばS3でも問題なさそう。

[itochan]

ハッシュ値を束ねたDBを用意するって意味だろうけれど、逆にファイルのA属性フラグみたいなのを妄想した　＞テストをパスしたハッシュ値をどこかに保存しておいて、テスト実行前にそれを確認し、

[door-s-dev]

これは良さそうだな〜

[katsyoshi]

ちょっとこれ欲しかったやつなんだけど

[stefafafan]

なるほど、いかにも良さそう

[codehex]

CTO賢い

[hoppie]

🗒

[uraway]

ツリーのハッシュ値を含んだファイルのチェックサムをキーにしたらCircleCIのキャッシュ機能でできないかな？🤔

[Kesin]

expireが短くても問題なければツリーのハッシュ値をそのままキーにしてS3の代わりにCIサービスのキャッシュでも実現できるかも？。いっそ空ファイルの代わりにテスト結果のファイルをそのままキャッシュさせても