Sooey

2026-04-11 11:18:38 +0900

Hatchboxでデプロイが完了した時にNew RelicのReleaseを作成する方法

まず、Hatchboxのアプリに以下の環境変数を設定しておく。

  • NEW_RELIC_API_KEY: New RelicのUser API Key ("NRAK-*")
  • NEW_RELIC_ENTITY_GUID: New Relicのアプリ毎の識別子 (アプリ名横のiアイコンを押して"Metadata"タブで確認できる)

そのうえで、Hatchboxのアプリ毎の"Settings - Deploy Scripts - Post-deploy script"にて以下のスクリプトを設定する。

NR_API_KEY="${NEW_RELIC_API_KEY}"
NR_ENTITY_GUID="${NEW_RELIC_ENTITY_GUID}"

# 1. バージョン情報の取得 (REVISIONファイルがあれば使用、なければ日時)
DEPLOY_VERSION=$(cat REVISION 2>/dev/null || date +%Y%m%d-%H%M%S)

# 2. GraphQLクエリの組み立て
read -r -d '' JSON_PAYLOAD <<EOF
{
  "query": "mutation { changeTrackingCreateDeployment(deployment: {entityGuid: \"$NR_ENTITY_GUID\", version: \"$DEPLOY_VERSION\", user: \"Hatchbox\"}) { deploymentId } }"
}
EOF

# 3. New Relic APIへのリクエスト実行
curl -s -X POST 'https://api.newrelic.com/graphql' \
     -H "Api-Key: $NR_API_KEY" \
     -H "Content-Type: application/json" \
     --data "$JSON_PAYLOAD"

デプロイを実施してみて、デプロイログのApps::Deployで以下のような出力があれば成功。

-----> Deploy complete
-----> Running post deploy script on サーバー名...
-----> Post deploy script finished.

2026-03-10 21:58:09 +0900

7年ぶりの投稿

Heroku → Renderと移行してきましたが昨今は円安でコストが馬鹿にならないため、Railsアプリ稼働環境をConoHa VPS(+Hatchbox)に移行したので動作確認を兼ねてのポストです。

ついでにこのタイミングで

  • データベースをPostgreSQLからSQLiteへ
  • Litestreamを使ってSQLiteのS3へのレプリケーションを設定

という変更も行っておいた。

2018-06-05 12:29:40 +0900

Capybara 3.0.0にてCapybara::Element::Node#textなどの戻り値が変化する仕様変更があった

Capybara 3.0.0(厳密には3.0.0.rc2)にて、

  • Visibile text whitespace is no longer fully normalized in favor of being more in line with the WebDriver spec for visible text

という仕様変更が行われた結果、

element = page.first('.some-element')
expect(element).to have_content("Foo\nBar")

のように Capybara::Element::Node のコンテンツに対して「改行」や「連続する空白文字」を期待値としているテストが失敗するようになりました(実際の値として返される文字列が Foo Bar のようになるため)。

これはどうやら、「ブラウザ上での表示に近い文字列を返す」ようにする意図の変更のようです。

従来どおりにテストを成功させるための対応としては、

element = page.first('.some-element')
expect(element.native.text).to have_content("Foo\nBar")

のようにネイティブなオブジェクト経由で文字列を取得するようにすればよさそうです。

2017-11-18 16:46:20 +0900

rspec 3.7でOmniAuthのテストモードが失敗するようになった場合の対策。

rspec (rspec-rails) を3.7.xにアップデートしてから、Integration Testing · omniauth/omniauth Wikiにあるような OmniAuth.config.test_mode を使ったFeature specが失敗するようになってしまった場合は、Pumaがclusters modeで動作するように設定されていないか見直すこと。

具体的には、config/puma.rbHerokuの推奨する以下のような設定になっていると、

workers Integer(ENV['WEB_CONCURRENCY'] || 2)

テスト時にOmniAuthのモックがうまく設定されない状態でテストが実行されてしまうようになる。

これを、

if  ENV.fetch('RAILS_ENV') { 'development' } == 'test'
  workers 0
else
  workers Integer(ENV['WEB_CONCURRENCY'] || 2)
end

のようにしてclusters modeでは動作しないようにした状態でテストを実行すると、おそらく従来通りの結果が得られる。

他にも VCR.use_cassette '...' { ... } のようにVCRで囲んだ部分でもリクエストをフックしてモックデータを返すような動作をしなくなるなど、clusters modeにしていることによってハマることがある。

2017-08-29 13:13:38 +0900

PhantomJSからChromeDriverに移行した場合にテストでダイアログのボタンをどのように押すか

Poltergeist + PhantomJSという組み合わせでRailsアプリのFeature specを書いている場合、JavaScriptのalertやconfirmでダイアログが開かれた時には常にOKボタンが押されるようになるため、クリックすると確認のダイアログが開くようなボタンを押すテストは以下のようなコードで実行することができる。

find("#button-with-confirm").click

これを、ChromeDriveとselenium-driverを使ったFeature specに移行した場合、以下のようにCapybaraのaccept_alertを利用して明示的にダイアログのボタンを押すようなコードにする必要がある。

accept_alert do
  find("#button-with-confirm").click
end