これわかる...
階層分けもわけわからんし
わんせた(@ars42525@odakyu.app)の投稿
For those who wants information about Yuito, subscribe my English posts only (available on account profile, Mastodon v4 or above).
くだらないこと言ってる人格は わんせた 、コード書いてる人格は kyori
呼ぶときは わせたん でもよし。たんってついてればかわいいので
Manages: https://odakyu.app https://nitiasa.com
Maintains: https://accelf.net/yuito (fork of Tusky)
when these instances down see here: @ars42525 @ars42525
Server Status: https://graph.accelf.net
Dockerわけわからんくなってきた
Dockerで作った開発環境でDockerで動かすアプリ開発するの混乱する
no-cacheビルド、もしRubyとかビルドしなくていいならマルチステージビルドの一段階目をスキップしても問題ないので、--cache-fromで一段階目のイメージを指定してあげればすごい早くなるはず
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
今回は自前で保存/復元するのに10分位かかってるから、あとでdocker pullならどれくらい高速化できるか試して見る予定
出来たぁ！！
CircleCIでのMastodonのDockerイメージビルドを50分から20分弱までガッツリ短縮！
(なおキャッシュの保存等に相当な時間を要する模様)
Continuous Integration and Deployment
https://circleci.com/gh/accelforce/odakyudon/113
の投稿
nyoki@v2.nyoki.club
このアカウントは、notestockで公開設定になっていません。
確定申告の投稿
2bo@mstdn.maud.io
このアカウントは、notestockで公開設定になっていません。
とりあえずcache効かせるには1回docker saveしなきゃいけないので2時間かかるけど待つしかない
--cache-fromでlatest指せばいいと思ってたんだけど、build-dep指すのが正しいみたい
なんかcache-fromするのが正解だったようです…(というかcache-fromを誤解してたかも
なんかすごく🤔なものを見た
先にdocker build --target build-depしてたのにそのキャッシュを一切使わないでまたいちからdocker buildしてるのバカでしょ
なんでbuild-dep使ってくれないのよ
の投稿
nyoki@v2.nyoki.clubこのアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
docker buildが終わるまで圧倒的に暇なんだけどどうしようかね()
【つ】月に叢雲華に風 / 幻想万華鏡/満福神社
by わんせた(ars42525)
#nanamusic
https://nana-music.com/sounds/04ae259b/
の投稿
shinderuman@ding-dong.asmodeus.tokyo
このアカウントは、notestockで公開設定になっていません。
[続 multi stageなDockerfileで中間イメージにタグをつける - Qiita](https://qiita.com/yagince/items/c1ca56331811fc8b33c1)
ほーん
相変わらずdocker buildを眺めながら歌う日々
【ち】CheerS / ClariS
by わんせた(ars42525)
#nanamusic
https://nana-music.com/sounds/04ae20ae/
そんでCircleCIではbuild-depとlatestを両方pullして、順番にbuildかければいい気がする！
先にbuild-depをbuildしてbuild-depごとpushしておけばキャッシュが効くのでは！！！
docker pullしてから--cache-from指定とかdocker saveしたやつをloadしてからビルドとかいろいろやってるんだけど一向にdocker build時にキャッシュ使ってくれないのなんなの？
ローカルに(ブラウザに)キャッシュされちゃってるからCloudFlareパージしてもダメだと思われる(CloudFlareのキャッシュはそもそも通さないように設定した
もしかしたら /inbox とか /outbox とか事故ってたりする？
気づきようないけど可能性あるよね？
> まさにこれ、利用しているサービスがわけわからん状態になってる
https://twitter.com/nakazavva/status/1108199829954424832
そこかしこで事故ってるらしくて共感を得られました...w
このアカウントは、notestockで公開設定になっていません。
とりあえずCloudFlareヤバいっぽいんでDevelopment Modeにしとくといいと思います
効果あるかわからんけど
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
@mayaeh ページを再表示した時にリクエストしないでキャッシュだけで表示するのは多分ブラウザの仕様ですね…
表示速度を優先してる気がする
@mayaeh 普通こうならないんだとしたらこれはCloudFlareのせいですね...w
でも今回の問題とは関係ないと思います
@mayaeh ストリーミングで入ってた分だけ全部消えて初期にapiで入ってた分だけになりますね
これうちはもとからこんな感じです
多分ストリーミングでは飛んできてるんだけど、TuskyExに通知ストリーミングがないからわからないだけです
これたぶんCloudFlareかtootsuite/masterどっちかやらかしてる
改造しまくってるとは言ってもこれはおかしすぎる
CloudFlareにしたことによってクライアントにキャッシュさせる時間を伸ばされてる可能性とかはあるかも
CloudFlare、さすがにAPIの返事とかはキャッシュしないのでTLが更新されないことはないような…
ごちゃまぜLTL消したら処理時間がだいぶ短くなったね…
まだローカルのユーザーがトゥートした時の処理時間が長いから多分STLのせいだ
まじかー女だったのかー()
~~~~~~~~~~
[https://odakyu.app/@sagami_tama/101779833038658124]
このアカウントは、notestockで公開設定になっていません。
#kyoriobjstorage
367.0047262022272G 86 objects s3://itabashi-backup/
136.82464628852904G 903580 objects s3://media.n-sr.org/
66.88234627153724G 374195 objects s3://media.nitiasa.com/
128.71490700077266G 791287 objects s3://media.odakyu.app/
70.05552563071251G 93 objects s3://nitiasa-backup/
186.48033542651683G 102 objects s3://odakyu-backup/
625.4574699401855M 48 objects s3://storage.accelf.net/
--------
956.5732851307839G Total
