git-set-mtime を Docker のためにリリースした
Docker のキャッシュは mtime ベースっぽい - 鳩舎 って話は前にしたんだけど、そんでじゃあどうするのっていう解決策がなかったので、 CI サーバー上で都度ソースをひっぱってくるような場合でも Docker のキャッシュを効かせるために、 git-set-mtime を作った。
インストールは rubygems から gem install git-set-mtime
でもいいし、go の場合は go get github.com/rosylilly/git-set-mtime
でもよい。
インストールしたら git set-mtime
を実行すればカレントディレクトリ以下のファイルの mtime をそのファイルが最後にコミットされた時刻にしてくれます。
なんかあったら Twitter で @rosylilly に言うとかしてください。
追記
主に僕が Circle.CI 上で使いたいというのにインストールがだるすぎて萎えたので drone.io からビルド済みのバイナリを落とせるようにした。
ここから Windows, Mac, Linux 向けのバイナリが落とせます。全部 64-bit 環境向け。32-bit は要望来たらやる。
SSHKit within as 順序 意味なし
ruby の SSHKit というのがあって、まぁいろいろ端折ると
on "10.0.0.1" do as :root do within "/tmp" do execute :echo "Hello > log" end end end
みたいなのが書けて、『あー 10.0.0.1
に入って root
に sudo
して /tmp
に cd
して echo
するんだなー』みたいな感じの見た目になるが そんなことは一切ない 。
上記の記述で行われる処理の流れは
cd /tmp
sudo -u root echo Hello > log
の順に行われる。今回の場合は /tmp
なので問題にならないけど、コレが特定ユーザーのホームディレクトリで何かしたいとかの時になると途端に破綻する。
SSHKit は便利で最高!
Docker のキャッシュは mtime ベースっぽい
タイトルそのまんま。
Dockerfile
ではすでに ADD
したファイルの追加なんかはキャッシュされるのでスキップされる
# Dockerfile FROM ubuntu ADD text text
こんな感じの Dockerfile
があったとして、これを2回ビルドすると、2回めの時には
Step 1 : ADD text text ---> Using cache ---> 9839a3ce35ab
みたいな表示になって、キャッシュの内容が使われる。
この後に touch text
をすると
Step 1 : ADD text text ---> a4f64ca64ba7
てな具合に Using Cache
がなくなって、またビルドが実行される。
ローカルだとほぼ問題ない挙動なんだけど、 CI 上でコンフィグを書き出してたりとかするとハマることがおおい(僕は s3cmd の sync ではまった)。
お気をつけて。
github.com のソースコードプレビューでタブ幅8で困っている人向け
.code-body .line, .file-diff .file-diff-line { tab-size: 2; -moz-tab-size: 2; -o-tab-size: 2; }
何らかの方法で上記の CSS を読み込むと2タブになります。4タブがいい人は2を4にしましょう。
go fmt は基本的に問答無用でタブインデントにするので、こういう設定が必要になるけど、考えてみたら各個人の環境で幅を設定出来るタブという選択肢は割とありなのかもしれないと思う。
適当に CLI から pushover に通知送る go app 書いた
https://github.com/rosylilly/pprocess
~/.pprocess.json
に
{ "token": "application token", "user": "user token" }
てな具合で設定を保存して、
$ go get github.com/rosylilly/pprocess $ pprocess -m "通知"
とか送ると、 Pushover 経由で通知が飛ぶ。設定は device
とか sound
も設定できるけど、僕の需要にないので多分動かない。
何はともあれこれのお陰で packer で AMI を作ってる間に洗い物してても終わったら通知が iPhone に来るようになった。なんでもかんでも無差別につながっていくの最高だと思う。
Object Design Rough Talks #1
Object Design Rough Talks というイベントを開催して、Points of View という内容で話ました。
いろんな意味で面白いイベントだったので、詳細なまとめはまたこんど。