最新バージョンではないMisskeyのフォークのテストが失敗するようになっている
Closed this issue · 15 comments
7ad169c （一つ前）を明示的に参照して対応できませんか？
バージョン更新してもらえば良さそう
更新するとか修正すれば直るのは直りますが…
全ての過去のソースコードのテストが使い物にならなくなっているということを重く見てほしいですね
過去のテストを現在になって実行することは想定していないわね
そんなに過去のテストでもないし1.2kの全てのmisskeyのフォークが常にdevelopを追従できるわけではないということをわかってほしい
- Misskeyはフォークの面倒までは見れない(そこまでの余裕がない)
- misskey-dev/misskeyをフォークするならmisskey-dev/assetsも同様にフォークしてもらった方が良さそう
Misskeyはフォークの面倒までは見れない
READMEとかに書いとくべきかしら
「fork向けの変更点とか発行してくれ」など「面倒」をみてほしいということではない
こういうテストに使われているリソースの変更に気を付けてほしい（すくなくとも時間をおいて消すなどをしてほしい）ということです
そもそもなのですがこれは「勝手に壊れた」という主張でしょうか？
git submoduleを正しく運用していればsubmoduleでcheckoutされるコミットは固定されるので勝手に壊れることはなく、更新したら壊れたということたまと思うのですが間違いないですか？
タイムラインのテストで main を参照しているため submodule 関係なく勝手に壊れますね (main ではなくコミットを指定していれば防げました)
とりあえずtestで参照されてるファイルだけ直下に置きなおすか
タイムラインのテストで main を参照しているため submodule 関係なく勝手に壊れますね (main ではなくコミットを指定していれば防げました)
それならテストをコミットハッシュに書き換えれば済む話かなと…
raw.githubusercontent.comを指定するなりする時はブランチではなくコミットハッシュやタグを参照すべきではあるとは思った
（それはそうと過去のソースコードのテストが動かないと言われても対応しきれないわけですが……）
タイムラインのテストで main を参照しているため submodule 関係なく勝手に壊れますね (main ではなくコミットを指定していれば防げました)
それならテストをコミットハッシュに書き換えれば済む話かなと…
個人的には、もう壊れてしまったものは仕方がないので、旧バージョンについてはそれで良い気はします。
現行のバージョンについては、次の破壊に備えてコミットを指定すると良いのではと思っていますが、どうでしょう。
次の破壊に備えてコミットを指定すると良いのでは
そうします
（旧バージョンはとりあえず #7 をマージすれば何とかなるはず）