Travis-CIで環境変数を使う
前回紹介したSendGrid-ReversiでTravis-CIを使った際に気になった箇所のメモを残します。
Travis-CIを使うためにはプロジェクト内に.travis.ymlという名前のファイルが必要です。とりあえず、リポジトリトップ下に置いてポチポチ設定すればいいみたいです。
今回はこんな感じにしてみました。
それぞれの詳細はTravis-CIのドキュメントを見ればよいのでポイントだけ。
これは、テストケースでSendGrid APIを使っている関係上、複数環境でテストをするとテストが並列実行されてしまい、SendGridがテストケースの想定していない状態になってしまい失敗(テンプレート削除のテスト中にテンプレート作っちゃったり)するためです。実行環境毎のテストをシーケンシャルに走らせるためのオプションを見つけられなかったのですが、そんなのあるんですかね?
SendGrid環境も分けるようにしないといけないんでしょうか。それはちょっとキツイなー、と。
今回、SendGridへのアクセスを行なうテストケースがあったので、そういった情報をどこに置くかが問題となりました。調べてみるとそういう情報は「Settings」に書けってTravis-CIのヘルプに書いてありました。Settingsはリポジトリ毎に設定できます。
.travis.ymlに書くのと同様、キーと値の組合せで書きますが、「Display value in build logs」をOFFにしておくと、非公開な環境変数として利用することができます。
ちょっと前までは「CIなにそれうまいの」状態でしたが、テストツールと同様、一度使ってしまうと、もう不安で不安で使わない状態には戻れませんね。麻薬みたいな効果があります。
Travis-CIを使うためにはプロジェクト内に.travis.ymlという名前のファイルが必要です。とりあえず、リポジトリトップ下に置いてポチポチ設定すればいいみたいです。
今回はこんな感じにしてみました。
language: ruby rvm: - "2.0.0" # - "2.1.0" env: - RACK_ENV=test services: - mongodb before_script: - bundle install script: - bundle exec rspec
それぞれの詳細はTravis-CIのドキュメントを見ればよいのでポイントだけ。
実行環境のバージョン指定は一つだけにしてみる
実行環境としてRubyを使っており、通常複数バージョン指定できるのですが、今回はバージョンを一つだけ(上の例だと"2.0.0"だけ)に限定してみました。これは、テストケースでSendGrid APIを使っている関係上、複数環境でテストをするとテストが並列実行されてしまい、SendGridがテストケースの想定していない状態になってしまい失敗(テンプレート削除のテスト中にテンプレート作っちゃったり)するためです。実行環境毎のテストをシーケンシャルに走らせるためのオプションを見つけられなかったのですが、そんなのあるんですかね?
SendGrid環境も分けるようにしないといけないんでしょうか。それはちょっとキツイなー、と。
晒したくない情報は.travis.ymlではなくSettingsを使う
環境変数は「env:」配下に書いておけばよいのですが、パブリックなリポジトリにアップされた .travis.ymlファイルは公開されてしまうため、晒したくない情報(サービスへのログイン情報など)は書けません。今回、SendGridへのアクセスを行なうテストケースがあったので、そういった情報をどこに置くかが問題となりました。調べてみるとそういう情報は「Settings」に書けってTravis-CIのヘルプに書いてありました。Settingsはリポジトリ毎に設定できます。
.travis.ymlに書くのと同様、キーと値の組合せで書きますが、「Display value in build logs」をOFFにしておくと、非公開な環境変数として利用することができます。
RACK_ENV=testを使ってみる
この環境変数は、Rackアプリをプロダクションとかステージングみたいな感じで環境を切り替える時に使う変数みたいです。
今回のアプリケーション内でこの環境変数を使っているのは、Mainクラスのconfigure部分(内部でSendGridの初期化を実行している)で、プロダクションのときだけconfigureするようにしています。
こうしておいて、RACK_ENV=testにすると、rspecでテストケースが実行されるたびにconfigureが実行されてしまうのを避けることができました。
今回のアプリケーション内でこの環境変数を使っているのは、Mainクラスのconfigure部分(内部でSendGridの初期化を実行している)で、プロダクションのときだけconfigureするようにしています。
こうしておいて、RACK_ENV=testにすると、rspecでテストケースが実行されるたびにconfigureが実行されてしまうのを避けることができました。
module Reversi class Main < Sinatra::Base configure :production do begin settings = Settings.new Configure.init_sendgrid(settings) rescue => e puts e.backtrace puts e.inspect end end
さいごに
ほかにもMongoDB使ったり、テスト前に実行されるbefore_scriptでbundle installしていたりします。ちょっと前までは「CIなにそれうまいの」状態でしたが、テストツールと同様、一度使ってしまうと、もう不安で不安で使わない状態には戻れませんね。麻薬みたいな効果があります。
コメント
コメントを投稿