git log ancestry-pathについて

git logの–ancestry-pathオプションがよくわからなかったので調べて見た。 まずこんな感じのコミットログを考える ここでgit log –graph –oneline 9103739..e3b7b68を実行すると、以下が出力される。 * e3b7b68 (HEAD -> master) I|\| * 659e5da (br-1) H| * bcb7e69 G| * a8b93fa (br-2) D* 2a3c429 F git logに<rev1>..<rev2>とrevisionを2つのドットで繋いで範囲にすると、「<rev2>の祖先のログから<rev1>の祖先を減算したログ」を出力する。 ここでgit log –graph –oneline –ancestry-path 9103739..e3b7b68を実行してみよう。 * e3b7b68 (HEAD -> master) I* 659e5da (br-1) H* bcb7e69 G a8b93faと2a3c429コミットがログから消えた。–ancestry-pathをつけていない状態ではa8b93faと2a3c429があったのに、つけるとa8b93faと2a3c429が消えた。この2つのリビジョンの法則性としては2つのドットの前に指定した9103739の子孫ではないということだ。 –ancestry-pathの働きは、「2つのドットの後ろにつけたリビジョンの子孫でないものを削除する」というものになる。 つまり、git log –ancestry-path <rev1>..<rev2>は、「<rev2>の祖先から<rev1>の祖先を削除し、さらに<rev1>の子孫でないものを削除する」意味になる。 これは結果的になにをしているかというと、「<rev1>から<rev2>の間にあるコミットだけ抽出」という結果になる。 2つのリビジョン間にあるコミットだけを抽出したい時、git log…

Macをサーバーにしてjenkins jnlpデーモンを起動させたとき、謎にterminatedになる現象

現象 Macをビルドサーバーとして、Jenkinsのjnlp slaveを起動していたのですが10数分〜1時間ぐらいで接続が切れる。 jnlp slaveはnohupとlaunchdでの起動試したがどちらも接続が切れる jnlp slaveをフォアグラウンドで起動していると接続は切れない masterのログをみても以下のようにしかでない コネクションが切断されました。 slave側のログをみても、「terminated」としか書いてない。 psコマンドでプロセスを見るとプロセスは生きている 原因 ssh接続を切っている間に、Macが自動スリープしていた Macで画面共有を有効化しているとき、ssh接続をするとスリープモードから自動復旧するらしく、利用者側からはスリープしてるようにみえなかった Macがスリープするので、プロセスも一時停止する→jnlp接続が切れる 対策 Preferences->省電力->ディスプレイがオフの時にコンピューターをスリープしない にチェックをいれるだけ 感想 1週間ぐらい悩みました。つらい

Dockerコンテナ内でssh keyを使う

Dockerコンテナでビルドパイプラインなどを作っていると、コンテナ内からgit fetchしたくなります。しかしsshでgit fetchしようとすると、コンテナ内との鍵の管理がめんどうになります。 コンテナ内でssh用の鍵を使う方法としては コンテナ用の鍵を生成してbuild時にコピーする ホストの.sshをコンテナにマウントする の2パターンが考えられます。 1の場合、ホストだけでなくコンテナ用の鍵をいちいち生成しなくてはならず、またGithubなどのdeploykeyに登録をしないといけなくなります。さらにDockerfileがgit管理されている環境ではコンテナ用のprivate keyをリポジトリにコミットしてしまう恐れもあります。 したがって2の場合を考えて行きたいのですが、普通に.sshをコンテナにマウントすると、.ssh/configのownerがホスト側のユーザーになってしまい、コンテナからsshしようとするとpermission errorになってしまいます。 解決策としては、マウント先は一時ファイルに.sshをマウントしておき、コンテナ実行時にコンテナのホームディレクトリにコピーすることで.sshのpermissionが正しくなります。 コンテナ実行時に.sshをコピーするために、ENTRYPOINTは以下のようなシェルスクリプトにします。 あとはdocker run時に.sshを一時ファイルへマウントすればOKです docker run -v /home/user/.ssh:/tmp/.ssh

[go][python] 依存パッケージのファイルは先にCOPYしてdocker buildを高速化する

docker buildすると依存パッケージのインストールが走ります。 理想的には依存パッケージに変更がなければ依存パッケージのインストールはキャッシュしたいところです。 しかしながらうまくDockerfileを作らないと毎回docker build時に依存パッケージのインストールが走ってしまいます。 依存パッケージのインストールをキャッシュするためには依存パッケージを記述したファイルのみ、先にCOPYしてパッケージのインストールを行います。 ソースコードはDockerfileの最後の方でCOPYします。 こうすることでソースコードに変更が合った場合、依存パッケージのインストールはキャッシュされ、ソースコードのコピーのみ処理が走ります。 goの場合、depパッケージマネージャを使うならGoPkg.tomlとGoPkg.lockのみ先にコピーします。 パッケージインストール時はdep ensure -vendor-only=trueにすることでソースコードの解析が走らずにパッケージのインストールが走ります。dep ensureのみで実行してしまうと、この部分がソースコードに依存してしまうのでソースコードに変更があるとパッケージの再インストールが走ってしまいます。 サンプル https://github.com/garicchi/docker-sample  

Hugっとプリキュアがあつかう、人生の困難への向き合い方

HUGっとプリキュアをご存知でしょうか。 毎週日曜日に放送されている女児向けアニメプリキュアシリーズですが今年のプリキュアは敵がブラック企業の比喩として描かれていて個人的に非常にヒットしています。 そのHUGっとプリキュア33話、「要注意!クライアス社の採用活動!?」は久しぶりに考えさせられる回でした。 特に最後、今作の敵であるクライアス社の社長であるプレジデントクライが、自社の採用に失敗したことを「救えなかった」と表現しています。クライアス社の目的は「時間を止めて永遠の幸せを手に入れる」ことですが、そのことを「救い」と表現しているのです。 ある思想があり、そのために仲間を引き入れることを「救い」と表現することは、現実で言うなれば新興宗教です。つまりプリキュアの敵であるクライアス社はブラック企業の比喩でもありますが、新興宗教の比喩でもあります。 救いとはつまり、困難な状況に対し、その新興宗教に入信し、思想を受け入れることで困難な状況を解決することです。プリキュアたちはその思想にたいし、きっぱりとNOと言います。しかしながら人生には困難がつきもので、自分がいくら強くても他人のことばかりを気にする時代であり、他人から困難が降り注ぐことが多々あります。 HUGっとプリキュアではそこに対するアプローチが提示されています。プリキュアは人生に困難が立ちはだかったとき、「自分を愛し、人を愛する」というアプローチを提示しています。新興宗教に入信する人はたいてい、人生が辛く、自分を愛せなくなった状態の人が多いです。そこに対し、「入信すれば救われる」という他力本願な解決策を新興宗教は提示してきます。しかし他力本願では人生の困難を解決できるはずがありません。人生の困難を解決するのは自分自身であり、自分を愛することで乗り越えられる可能性をプリキュアは訴えています。さらにそれだけではなく、他人を愛することで他の人の人生を解決する力になれるかもしれないとも訴えられていると思います。他人に対する愛はあくまで解決する力になるだけで実際に解決するのは本人です。しかしながら新興宗教は入信していうとおりにすれば救われると提示することが多く、これは人生の困難にたいするアプローチの方法として、他力本願です。 このような人生の困難に対し、自力で解決するか、他力で解決するかを対比的に描かれているのが今作のプリキュアであり、他力で解決しようとする敵に対し、プリキュアは自己愛と他者にたいする無償の愛による解決を提示しています。