pecoでは何個か前のリリースからバイナリビルドをリリースの成果物として登録するようにしている。これのおかげでpecoはそもそもの存在理由である「2014年だしこういうツールはバイナリ一個置いておくだけで動いてほしい!」というをより簡単に実現できている。
で、その実装方法。基本motemenさんのスクリプトにmattnさんがツッコミを入れたりしてるのを見ながら「よし!パクろう!」と思ってパクったんだけど、一つだけpecoでは意図的に変えたところがあって、それはboxの選定のところ。
motemenさんのgolang-goxc box自体に基本何も問題がないのだけど、pecoで色々やっているうちにgo1.3がリリースされたのにこのボックスを使っているといつまでもgo1.2.1だった(今はもう違うかもしれない)。まぁ当たり前ですよね。そこは他人の褌で相撲を取ろうとしている俺が文句言うところではない。
ただやっぱりバイナリのサイズが小さくなったり、多少パフォーマンス改善も見られている1.3系を使いたいと思いが募ったのと「これから先もきっとこういう事があるだろうし、そういうことがあるごとに文句を言わないといけないのか?」という思いがあり、pecoにはpeco専用のビルドボックスを作る事にした。それがこちら。もちろんgo1.3とgoxcを入れているところ以外はたいした事してない。
たいしたことはしてないんだけど、よくよく考えればライブラリとかではなくpecoのようにエンドユーザーに直接届くプログラムに関してはあまり自分が制御できていない環境に依存するのもどうかなーと思ったのでもうボックスから作る事にしてしまった。これなら自分がやりたいタイミングでgo1.4が出たらgo1.4にすることもできるし、goxcの特定のバージョンが欲しい、とかにも対応できる。
あとはmotemenさんの元記事と一緒。タグ打ってgit pushすれば勝手にファイルがあがってくる。おっさんは何もする必要がありません。大変すばらしい。また時間のある時にはhomebrewのレシピも自動的に作成しようとは思ってるけどそこまで至っていない。ともあれ、自動化はすばらしい。
ちなみに、drone.ioも一応登録はしてあって、こっちでもリリースとかできるかやってみたんだけど失敗して、ただただコンパイルして成果物を残しているだけ(基本前のやつは上書き)。あんまり必要じゃないけど、別の環境でコンパイルするとたまにバグが見つかったりもするので悪くはないと思ってる。まぁそのうち消すかも。
で、その実装方法。基本motemenさんのスクリプトにmattnさんがツッコミを入れたりしてるのを見ながら「よし!パクろう!」と思ってパクったんだけど、一つだけpecoでは意図的に変えたところがあって、それはboxの選定のところ。
motemenさんのgolang-goxc box自体に基本何も問題がないのだけど、pecoで色々やっているうちにgo1.3がリリースされたのにこのボックスを使っているといつまでもgo1.2.1だった(今はもう違うかもしれない)。まぁ当たり前ですよね。そこは他人の褌で相撲を取ろうとしている俺が文句言うところではない。
ただやっぱりバイナリのサイズが小さくなったり、多少パフォーマンス改善も見られている1.3系を使いたいと思いが募ったのと「これから先もきっとこういう事があるだろうし、そういうことがあるごとに文句を言わないといけないのか?」という思いがあり、pecoにはpeco専用のビルドボックスを作る事にした。それがこちら。もちろんgo1.3とgoxcを入れているところ以外はたいした事してない。
たいしたことはしてないんだけど、よくよく考えればライブラリとかではなくpecoのようにエンドユーザーに直接届くプログラムに関してはあまり自分が制御できていない環境に依存するのもどうかなーと思ったのでもうボックスから作る事にしてしまった。これなら自分がやりたいタイミングでgo1.4が出たらgo1.4にすることもできるし、goxcの特定のバージョンが欲しい、とかにも対応できる。
あとはmotemenさんの元記事と一緒。タグ打ってgit pushすれば勝手にファイルがあがってくる。おっさんは何もする必要がありません。大変すばらしい。また時間のある時にはhomebrewのレシピも自動的に作成しようとは思ってるけどそこまで至っていない。ともあれ、自動化はすばらしい。
ちなみに、drone.ioも一応登録はしてあって、こっちでもリリースとかできるかやってみたんだけど失敗して、ただただコンパイルして成果物を残しているだけ(基本前のやつは上書き)。あんまり必要じゃないけど、別の環境でコンパイルするとたまにバグが見つかったりもするので悪くはないと思ってる。まぁそのうち消すかも。