artifacts のサイズ制限にかかってappveyor のビルドに失敗する
m-tmatma opened this issue · comments
artifacts のサイズ制限にかかってappveyor のビルドに失敗する
Maximum allowed artifact storage size of 50000 Mb will be exceeded.
AppVeyor が失敗するのでログを見てみると
Maximum allowed artifact storage size of 50000 Mb will be exceeded.
と最後に出ていました。
うーむ。
Ilya Finkelshteyn's Avatar Ilya Finkelshteyn on 27 Aug, 2018 08:58 PM
Retention policy is now in place. Also default absolute limit is increased. If someone's artifacts collection pace is faster than artifact retention policy, please open a new issue describing your specific situation.
このレスを意訳すると、
古い成果物を削除する基準を見直してデフォの容量増やしたよ。もし新しい基準よりも速いペースで成果物を作っていて困った人がいたら、新しいスレ立てて自分たち固有の状況を説明してちょ。
になる気がする。
（引用文は https://help.appveyor.com/discussions/problems/10253-maximum-allowed-artifact-storage-size-of-1000-mb-will-be-exceeded の最後で problem を閉じた人が書いたメッセージです。）
↑間違った
誰かissue立ててこないと対応してもらえない予感。
急ぎであれば、問い合わせお願いします
送りました。
appveyor/ci#2672
対応されたみたい。
appveyor/ci#2672 (comment)
master をリビルド中です。
タイトル修正
master のビルド通りました。
閉じます。
再度サイズを拡張するようにお願いしました。
appveyor/ci#2708
20日ちょっとで20GB使い切っていることを考えると、半年なら180GBぐらい必要な計算になってしまいますね。
まぁ、今の使い方は、極論すると、保有期間１日でもいいわけで、半年なんていらないんすよね。
CIで容量くってしまうなら、CIテストの時はDry Runするような仕組みがあってもいいかもですね。
artifacts を rotate するように依頼しましょうか？
artifacts を rotate するように依頼しましょうか？
artifacts の保持期間を短くするように依頼しておきました。
appveyor/ci#2708 (comment)
We extended your limit to 100Gb for now to unblock you, looking better solution.
100Gbになっちゃった。。。
再度サイズを拡張するようにお願いしました。
appveyor/ci#2708
#579 (comment)
で通った。
looking better solution.
何らかの対策はすべきでしょうね。今のペースだとまた1ヶ月後にはいっぱいになるでしょうから。
アーティファクトの整理します？
当面「allのみ or 個別のみ」にする、とか。
x64版が欲しい人は自分でビルドしてる気配があるので、
x64版のバイナリはリリース目途が立つまで回収しない、とか。
PR で作成されるアーティファクトの第一の目的はリリース代わりではなくデバッグだと思うんです。x64-Debug が一番バグを引き当てやすいかなと思って動作確認では最初に選んでいます。
ちゃんと見るときはPRブランチごとソースをフェッチしてDebugビルドするのでDebugのアーティファクトは不要と考えていました。x64については現状で試験提供の認識です。絶賛バシラー募集中ですが、自分でなりたいとは思っていません。
成果物を見るだけならwin32-Release派です。
実際に使われるバージョンにこそ対応する意味があると思うので。
当面「allのみ or 個別のみ」にする、とか。
#587 で個別のみにしました。
#587 マージによって、生成されるバイナリ量が半分になりました。
従来の倍のペースでPRしない限り、当分は大丈夫ってことですね・・・。
artifactsの保持期間については、根本的に別なあり方を認めてもらったほうがいい気もしています。
こちら側の立場でラクなのは制限を越えたら古いものから削除、ですがそれは難しいのかしら・・・。
恒例の時期がやってきました。
https://ci.appveyor.com/project/sakuraeditor/sakura/builds/21088621/job/q5f33l77ws3x8vw4
10/26 ～ 12/19 の 54日間で 30GB 使ったことになる。
#587 を入れたので、まあ予想通り。
再度サイズ制限を拡張してもらえるように依頼しました。
appveyor/ci#2708 (comment)
恒例の時期がやってきました。
https://ci.appveyor.com/project/sakuraeditor/sakura/builds/21088621/job/q5f33l77ws3x8vw410/26 ～ 12/19 の 54日間で 30GB 使ったことになる。
#587 を入れたので、まあ予想通り。
対応してもらった。
リビルドかけた。
失敗してた PR はすべてビルド通った。
サイズ制限はアカウント単位らしい
appveyor/ci#2789 (comment)
zip形式から7z形式に変えればさらに半分くらいに減るかもしれません。
（7zの圧縮は遅いので、ビルド時間は確実に延びますが。）
手元で試してみましたが、サイズの半分ぐらいがchmファイル(=圧縮済み)なので劇的には変わらないっぽいです。(ASMの方は半分ぐらいになりました。)
やっぱりdoxygen要らないのでは？ｗ
doxygen生成のchmでかすぎ・・・
ソース触る人が地図代わりにできるように吐き出すものなので、
releaseには要らないのかも・・・とか言い出すとまた複雑な実行制御を組み立てる話にｗ
作り方だけ共有して、appveyorでは作らない、というのも選択なのかも知れませんね。
再度サイズ制限を拡張してもらえるように依頼しました。
appveyor/ci#2708 (comment)
19 Dec 2018
から半年以上たっている。
当時と比べて開発スピードは格段に下がっているが(ビルドされる頻度が下がっているが)、
7 か月発生していないので閉じます。