【入門】Jenkins (CI) + Ruby on Rails 3.2.x (RSpec) + GitHub + Amazon EC2 (Amazon Linux AMI) を使った継続的テスト【更新:2013-10-29】
前置き
最近、扱っている Rails アプリケーションの規模が少し大きくなってきたので、
そろそろちゃんとテストを書かないとなぁと思っていた。
私はテスト (CI) に関して次のような考えを持っている。
テストの実行は第三者がおこなう
人はどうしても怠惰な方に流されやすい生き物だと思う。
私も「ちゃんとしっかりテスト(書いて・実行)しよう!」という意思が薄いタイプの人間に思える。
なので、テストの実行と、失敗時の通知は、自分ではない「第三者」がやってくれないと困る。
サボってたら叱ってくれる人がいてほしい。
テストの成功・失敗の履歴は残しておくべき
テストがチェックインごとに正しく実行され、どのチェックインでテストが壊れたのか。
それはきちんと管理されているのが望ましいと思う。
いつの間にか、テストが壊れており、どのチェックインで壊れたのかわからない。
という状況は避けたい。
というわけで Jenkins (CI) を導入することにした。
構成について
今回、下記のような構成のテスト環境をつくった。
この記事では、その環境構築の流れを説明しようと思う。
Jenkins の構築と運用は、今回はじめてイチから行ったので、
いくらか不明確な部分や、誤り、非効率なところを含んでいると思う。
Jenkins の運用に慣れてきたら、いずれ書きなおす予定。
- Jenkins (CI) 1.522
- Web アプリケーションフレームワーク:Ruby on Rails 3.2.x 系
- テスト:RSpec 2.12.0
- 仮想サーバー:Amazon EC2 (Amazon Linux AMI 2013.03.1)
- コードリポジトリ:GitHub ( Private Repository )
- データベース:MySQL 5.5.x 系
※ MySQL データベースサーバーは、別インスタンスに事前に準備されていると仮定してすすめる。
話は少し変わって、「Travis CI」という継続インテグレーションサービスがある。
GitHub の Public リポジトリにチェックインしているコードならば、この「Travis CI」を先に検討したほうが良いと思う。
Jenkins の環境構築と、メンテナンスを自分でやらなくてすむ。
Private リポジトリに対しても「Travis CI」を使うことはできるが、値段が高い → http://travisci.com/plans
自分で Jenkins サーバーを立てる機会は、まだまだあると思う。
参考記事
Jenkins 入門・セットアップに関する記事を、いくつか読んでみたが、
私は下記の2つの記事が、特に役立った。
ステップバイステップ1:EC2 インスタンスを準備する
この項の目的は、下記の通り。
- Jenkins のインストール前に必要な、EC2 インスタンスのセットアップを行う。
EC2 インスタンスを Launch
EC2 インスタンスに必要なライブラリ等をインストールする
SSH で接続し、下記のコマンドを実行。
$ sudo yum update # 経験的に下記のパッケージは最初に入れておくと、トラブルが少ない(と思う) $ sudo yum -y install gcc gcc-c++ make zlib zlib-devel openssl openssl-devel apr-devel readline readline-devel curl-devel libxml2 libxml2-devel libxslt libxslt-devel # MySQL サーバーへ接続するためのクライアントライブラリ系のパッケージ $ sudo yum -y install mysql mysql-common mysql-devel mysql-libs # Git を使うのでインストール $ sudo yum -y install git # Rails 3.1.x 系以上を使うときは、事前に nodejs を入れておいたほうがいい(と思う) # 最新版は http://nodejs.org/ をチェックする $ wget http://nodejs.org/dist/v0.10.12/node-v0.10.12.tar.gz $ tar zxvf node-v0.10.12.tar.gz $ cd node-v0.10.12 $ ./configure $ make # ← Small インスタンスだと 30 分以上、時間がかかります $ sudo make install # nodejs のインストールを確認 $ node -v # RVM (Ruby Version Manager) を Multi User Install モードでインストールする # 個人的には rbenv よりも rvm のほうが好き。 # rvm は結構インストール方法が変わることがあるので、公式サイトで最新の方法を確認したほうがベター # → https://rvm.io//rvm/install/ $ \curl -L https://get.rvm.io | sudo bash -s stable --ruby=1.9.3 # ruby 1.9.3 系を初期インストール $ source /usr/local/rvm/scripts/rvm # rvm によって "rvm" というグループが追加されている # gem install を実行したいユーザーは、すべて rvm グループに含ませておいたほうが良い $ cat /etc/group # 確認 # 追加 $ sudo usermod -a -G rvm ec2-user
ステップバイステップ2:Jenkins をインストールする
RedHat Linux RPM packages for Jenkins (公式)
http://pkg.jenkins-ci.org/redhat/
下記のコマンドで Jenkins がインストールできる。
$ sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo $ sudo rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key $ sudo yum install jenkins
Jenkins の起動確認する。
$ sudo service jenkins start # Jenkins 起動 $ sudo service jenkins stop # Jenkins 停止 $ sudo service jenkins status # Jenkins ステータス
この状態で、Jenkins を立てている EC2 instance にアクセスする。
http://ec2-xxx-xxx-xxx-xxx.us-west-2.compute.amazonaws.com:8080
ホスト名は、EC2 instance の Public DNS を使う。
サーバーリブート時の自動起動を設定する。
$ sudo chkconfig jenkins on
$ chkconfig # ← 確認
ステップバイステップ3:Jenkins でテストを実行する
このステップは少々長い。
まず Jenkins のアカウント・セキュリティの設定を最初に行うことにする。
- 「Jenkinsの管理」→ 「グローバルセキュリティの設定」
- 「セキュリティを有効化」を ON
- 「アクセス制御」→「ユーザー情報」
- 「Jenkinsのユーザーデータベース」を ON
- 「ユーザーにサインアップを許可」を ON
- 「アクセス制御」→「権限管理」
- 「行列による権限設定(プロジェクト単位)」をON
- "admin" というユーザーを追加する
- 権限は「全て」を ON
- "github" というユーザーを追加する
- 権限は「全体」の「Read」のみ ON
- 「行列による権限設定(プロジェクト単位)」をON
- 保存 or 適用
画面をリロードすると、認証処理が動くようになるため「ログイン画面」が表示される。
先ほどのユーザー追加では、ユーザーの「権限情報の設定」のみを行っただけで、
実ユーザー情報「admin」と「github」はまだ作成されていない。
下記の手順で「admin」と「github」ユーザーを作成(サインアップ)する。
- ログイン画面の「メンバーでない人は、アカウントを登録してください」をクリック
- 「admin」というユーザーを作成する
- 作成できたらログアウト
- 「github」というユーザーを作成する
- 作成できたらログアウト
- 「admin」というユーザーを作成する
「admin」と「github」を無事作成できたら、サインアップ処理は一旦不要な機能となる。
この状態のままでは、匿名の誰かが自由勝手にユーザーをサインアップできてしまうのでサインアップ処理を禁止しよう。
- 「admin」でログイン
- 「Jenkinsの管理」→ 「グローバルセキュリティの設定」
- 「セキュリティを有効化」→「ユーザー情報」→「Jenkinsのユーザーデータベース」
- 「ユーザーにサインアップを許可」を OFF
- 適用 / 保存
次に Jenkins にいくつかのプラグインをインストールする。
今回、RSpec テストの実行と、Git の操作が含まれていることから次のプラグインインストールを推奨。
プラグインのインストール方法は、次の通り。
- 「Jenkinsの管理」→ 「プラグインの管理」→「利用可能」
- 「再起動せずにインストール」をクリック
- 「インストール完了後、ジョブがなければJenkinsを再起動する」をクリック
これでプラグインのインストールは完了。
次に、テストを実行するための Jenkins 上のプロジェクトを作成する。
今回テストを Jenkins に実行させたいプロジェクトを、仮に「example」プロジェクトとする。
GitHub 上にも「https://github.com/komiyak/example」というプロジェクトが、すでに作成済みであるとする。
- 「Jenkins」→「新規ジョブ作成」
- ジョブ名は「example」
- 「フリースタイル・プロジェクトのビルド」を ON
- OK
プロジェクトの設定は以下の通り
- プロジェクト単位でユーザーに権限を与える
- 「権限設定(プロジェクト単位)の有効化」を ON
- "admin" ユーザーを追加
- 「全て」を ON にする
- "github" ユーザーを追加
- 「Read」と「Build」を ON にする
- 「権限設定(プロジェクト単位)の有効化」を ON
- 「ソースコード管理」
- 「Git」を ON にする
- 「Repositories」→「Repository URL」に「git@github.com:komiyak/example.git」を追加
- 「ビルド・トリガ」→「SCMをポーリング」を ON (GitHub の Push をトリガにテストを実行するために重要!)
一旦、この状態で保存する。
プロジェクトのトップページに戻って「ビルドを実行」してみよう。
するとビルドに失敗するはず。コンソールを見ると「ERROR: Error cloning remote repo 'origin' : Could not clone git@github.com:komiyak/example.git」というエラーが出ていると思う。
リポジトリを正しく見にいけてない状態なので、その設定を今から行う。
ssh で Jenkins サーバーへアクセスして、ssh の設定と GitHub への反映までを行う。
AWS EC2でJenkinsとGitの連携
http://kkurahar.github.io/blog/2013/03/14/jenkins-git-on-aws/
上記の記事にもあるのだが、Jenkins をインストールすると「jenkins」という linux user が作成される。
これはログイン不可ユーザーとして作成されている。
大抵の場合、初期設定値は「推奨」値であることが多いため、
これをログイン可能ユーザーに変えてしまうのはあまり良くないような気もするのだが、
今回は私も「jenkins」をログイン可能ユーザーへと切り替えて作業した。
$ sudo vi /etc/passwd # 下記の行を書き換える # jenkins:x:220:498:Jenkins Continuous Build server:/var/lib/jenkins:/bin/false jenkins:x:220:498:Jenkins Continuous Build server:/var/lib/jenkins:/bin/bash
次に jenkins ユーザーが GitHub からソースコードをチェックアウトできるように、公開鍵を作成する。
# jenkins ユーザーも rvm を使えるようにする $ sudo usermod -a -G rvm jenkins # jenkins ユーザーに切り替える $ sudo su - jenkins # jenkins ユーザーのホームディレクトリに移動 $ cd # ssh 公開鍵を作成 $ mkdir .ssh $ chmod 700 .ssh $ ls -la # ← .ssh のパーミッションが 「drwx------ jenkins jenkins」 になっていることを確認する $ cd .ssh/ $ ssh-keygen -t rsa # パスフレーズ(passphrase)は付けないこと。Enter passphrase (empty for no passphrase) で 何も入力せずに Enter # 公開鍵(id_rsa.pub)と秘密鍵(id_rsa)が作成されているので、公開鍵(id_rsa.pub)の方をコピーしておく # 秘密鍵は絶対に流出させないこと $ cat id_rsa.pub > ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCQ9Hsde+9QKmHDZ5extAF/Uu0xW01cPo8WKz5i2QFA5wg2Bel2P3548p0nFegsBUO5mEttRMAnkd5miq0YN88RgTOHp/iz1Ck6cnmBaLke1ogcRx7qiwqnjbA3QmUMbZUW+JAeh085AxdFYEFefi3OxBFR5lHO/V3Jg+XQ40v/cObMeHBfjLOU1Z9L30cOzfZzaAlD/qm6CdnxdTaR3qhMxtT0t0c7ixP7MUJzK3fHxnl1MOkonjX633k0FyG/DXHfFGxr+yOyAcB/f1CQfUJl+ueRJYR5W+9Az7EKu+zTC8zb7QYR47qTTP6S4XA7vsizL19Wfhbq7TKsrwU4tEBF jenkins@ip-xxx-xxx-xxx-xxx # ↑ この公開鍵の内容をコピーして持っておく
【2013-10-29 加筆修正 (start ---) 】
次に、いま作った公開鍵を、GitHub のプロジェクトに登録する。(※プロジェクトは Private リポジトリを想定)
これによって、Jenkins が「GitHub さん、テストを実行したいので最新のコードを下さい」とお願いすると、
「このプロジェクトは Private なものだけど、あなた(Jenkins)はアクセス認可されてますね。はいどうぞ!」というふうに、
ソースコードをチェックアウトできる。
GitHub にはこの公開鍵を設定するやり方が、どうやら二通りある。
- 「Account Settings」→「SSH Keys」→「Add SSH Key」
- 「任意のリポジトリ」→「Settings」→「Deploy Keys」→「Add deploy key」
今回のように、Jenkins から Private リポジトリに対して普遍的なアクセス認可を与えたい場合は、
(1)の「Account Settings」のほうがよい。
この1箇所に設定さえすれば、すべての Private リポジトリに対してアクセス可能になる。
(2)の場合は、そのリポジトリのみに認可を与えるが、
GitHub では1つの公開鍵を、複数のリポジトリに対して「Add deploy key」しようとすると、
「"Error: Key already in use"」という問題がおきる。
(※ Thanks! => http://qiita.com/yuch_i/items/44d224112382b5f1c8eb)
(1)の手順は次のとおりだ。
- 「Account Settings」→「SSH Keys」→「Add SSH Key」をクリック
- Title : 「jenkins(任意のもので可)」と入力
- Key :先ほどコピーしておいた公開鍵「ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCQ9Hsde+9QKmHDZ5extAF/Uu0xW01cPo8WKz5i2QFA5wg2Bel2P3548p0nFegsBUO5mEttRMAnkd5miq0YN88RgTOHp/iz1Ck6cnmBaLke1ogcRx7qiwqnjbA3QmUMbZUW+JAeh085AxdFYEFefi3OxBFR5lHO/V3Jg+XQ40v/cObMeHBfjLOU1Z9L30cOzfZzaAlD/qm6CdnxdTaR3qhMxtT0t0c7ixP7MUJzK3fHxnl1MOkonjX633k0FyG/DXHfFGxr+yOyAcB/f1CQfUJl+ueRJYR5W+9Az7EKu+zTC8zb7QYR47qTTP6S4XA7vsizL19Wfhbq7TKsrwU4tEBF jenkins@ip-xxx-xxx-xxx-xxx」を入力
- 「Add Key」をクリック
【2013-10-29 加筆修正 (--- end) 】
最後に重要な操作をもう一つ。
jenkins から GitHub にアクセスする時に、最初の一度だけアクセス確認の処理が走る。
これを事前に一度済ませておく必要がある。
Jenkins のサーバーへ ssh でアクセスし、次のコマンドを最初の1度だけ実行すること
$ sudo su - jenkins # jenkins ユーザーでログイン
$ ssh git@github.com
この操作により、具体的に .ssh/known_hosts に GitHub は安全なアクセス先であるという情報が登録される。
長かったが、これにより GitHub からコードをチェックアウトする準備ができた。
Jenkins の Web Console 上から「ビルドの実行」をクリックしてみよう。
ステップバイステップ4:Jenkins で(Ruby on Rails + RSpec)テストを成功させる
実はまだ終わりではない。
先ほどのテストは、ただ単に GitHub からソースを正しくチェックアウトできただけで、RSpec を実行できていない。
ここからは、すでにプロジェクトに RSpec のテストが書かれていることを前提に、
テストが実行されるまでの流れを説明する。
ssh 接続で RSpec の実行を試す
まず、Jenkins の Web Console 上からではなく、ssh 接続した上で RSpec を実行し、テストが成功するかを試す。
Jenkins の稼働サーバーに ssh で接続してほしい。
$ sudo su - jenkins # jenkins 上のプロジェクトディレクトリへ移動 # プロジェクト名が「example」の場合↓ $ cd /var/lib/jenkins/workspace/example # Rails アプリケーションの Database への接続情報を作成する $ vi config/database.yml
接続先の MySQL サーバーの IP を仮に 192.168.1.10 とすると
test: adapter: mysql2 database: example_test host: 192.168.1.10 port: 3306 username: root encoding: utf8 pool: 5 timeout: 5000
のように記述する。
次に RSpec を実行してみる。
# test 用の gem のみ bundle install $ bundle install --path vendor/bundle --without production development # test 用DBの準備 $ bundle exec rake db:create RAILS_ENV=test $ bundle exec rake db:migrate RAILS_ENV=test # RSpec の実行 $ bundle exec rspec spec/
rspec コメンドの実行が無事に成功すれば OK 。
ruby に関しては、事前に rvm でインストールしているので、問題ないはず。
jenkins で ruby を認識していない場合は、"jenkins" が "rvm" グループにちゃんと含まれているのかどうかを、もう一度確認するとよい。
そういえば、余談だが、上項の bundle install による gem インストールは鬼門でいろいろな原因で失敗することが多い。
Jenkins でテストする上で、特別に私が入れる必要になったのは 'therubyracer' ぐらいか?
rails3 のアセットパイプラインで必要になる gem なので、予め含めておくほうが無難かもしれない。
↓ 私の今回のサンプルプロジェクトの Gemfile
source 'http://rubygems.org' gem 'rails', "~> 3.2.0" gem 'mysql2', "~> 0.3.12b6" gem 'bcrypt-ruby', :require => 'bcrypt' # To use ActiveModel has_secure_password # Gems used only for assets and not required # in production environments by default. group :assets do gem 'sass-rails', '~> 3.2.0' gem 'coffee-rails', '~> 3.2.0' gem 'uglifier' end gem 'jquery-rails' group :development do gem 'debugger' end group :development, :test do gem 'rspec-rails', '~> 2.0' end # Deploy with Capistrano gem 'capistrano' gem 'therubyracer'
Jenkins から RSpec を実行する
いよいよ全ての下準備が整った。
Jenkins の Web Console にアクセスして、RSpec を実行するための設定を書き加えよう。
- 「Jenkins」→「example(今回のプロジェクト)」→「設定」→「ビルド」→「ビルド手順の追加」→「シェルの実行」
- 下記の設定を記述する
#!/bin/bash source /usr/local/rvm/scripts/rvm export PATH="$PATH:/usr/local/rvm/gems/ruby-1.9.3-p448/bin:/usr/local/rvm/gems/ruby-1.9.3-p448@global/bin:/usr/local/rvm/rubies/ruby-1.9.3-p448/bin:/usr/local/rvm/bin" export GEM_HOME="$GEM_HOME:/usr/local/rvm/gems/ruby-1.9.3-p448" rvm use 1.9.3-p448 cd /var/lib/jenkins/jobs/example/workspace bundle install --without development production --path vendor/bundle bundle exec rake db:migrate RAILS_ENV=test bundle exec rake db:test:prepare RAILS_ENV=test bundle exec rspec spec/
この設定で「ビルドを実行」すると、こんどこそ本当に RSpec のテストが実行されると思う。
では「シェルの実行」の内容について詳しく解説する。
正直、この設定に至るまでかなり大変な思いをした。
Jenkins には Ruby を簡単に扱うためのプラグイン、Rake を扱うためのプラグインが揃っているようにみえるのだが
私自身が勉強不足で全然使いこなせなかった...。(というか動かせなかった)
いろいろ調べまわったのだけれど、結局「シェルの実行」に実行内容を直接記入するのが一番はやいと決断した。
上から順番に説明しよう
#!/bin/bash
この入力部分を bash として処理させるために、必ず書いて置かなければならない。
最初書いてなくて、全然コマンドが通らず、混乱してしまった。
source /usr/local/rvm/scripts/rvm
rvm の環境設定をロードさせる。
jenkins ユーザーでログインすると、この辺りは自動で読み込まれているはずなのだが
いちいち明示的にしてあげなければならない。
export PATH="$PATH:/usr/local/rvm/gems/ruby-1.9.3-p448/bin:/usr/local/rvm/gems/ruby-1.9.3-p448@global/bin:/usr/local/rvm/rubies/ruby-1.9.3-p448/bin:/usr/local/rvm/bin" export GEM_HOME="$GEM_HOME:/usr/local/rvm/gems/ruby-1.9.3-p448"
環境変数「PATH」と「GEM_HOME」に ruby 関係のパスを通す。
PATH や GEM_HOME はパス指定の順番も重要な意味があるので、必ず export PATH="$PATH:..." のように
$PATH をはじめに書くようにしてほしい。
(私はこの初歩的な罠に引っかかった)
rvm use 1.9.3-p448
rvm use も明示的に。
cd /var/lib/jenkins/jobs/example/workspace bundle install --without development production --path vendor/bundle bundle exec rake db:migrate RAILS_ENV=test bundle exec rake db:test:prepare RAILS_ENV=test bundle exec rspec spec/
ここは純粋なビルドプロセス。
ソースが変更された時のことを考えて、bundle install, migrate も一緒に行うようにする。
補足1:GitHub にコードを Push したときに、Jenkins のビルドが自動で動くようにする
これは蛇足だが、こういう設定はいずれ行うと思うので
ついでに解説しておく。
やりたいこととしては、GitHub にソースコードを Push したときに
GitHub から Jenkins に「コードが新しくなったから、テスト実行してよ」と通知を飛ばすようにする。
その通知を受け取った Jenkins がテストを自動で実行する。という流れだ。
※ Jenkins には GitHub 用のプラグインもあるが、今回はそれを使用していない。
GitHub のプロジェクトに設定を行おう。
- https://github.com/komiyak/example (今回のプロジェクト)へアクセス
- 「Settings」→「Service Hooks」→ 「Jenkins Git plugin」をクリック
Jenkins の稼働しているサーバーの IP(ホスト名でもよい)を「xxx.xxx.xxx.xxx」とした場合、
次のような書式でフォームに記入を行う。
http://xxx.xxx.xxx.xxx:8080/git/notifyCommit?url=git@github.com:komiyak/example.git
このフォーマットについては、下記の記事が参考になると思う。
Jenkinsを使ったiOSアプリビルド自動化11 GitHubとJenkinsの連携
http://nantekottai.com/2012/07/13/git-hook-and-access-controlled-jenkins/
Gitプラグインを使った設定方法については、Jenkinsの作者でもあるKohsuke Kawaguchiさんのポスト「Polling must die: triggering Jenkins builds from a git hook」にて説明されていますが、Gitプラグインが有効になっている状態で
http://Jenkinsサーバー/git/notifyCommit?url=gitのレポジトリURL
というURLを叩くと、Jenkins側でそのレポジトリに関連するすべてのジョブが実行されます。GitHubのレポジトリのService Hooks上からJenkins (Git Plugin)を選択し、ここでこのURLをセットし「Active」にチェックをつけましょう。
この設定が整った状態で、GitHub にコードを Push してみると、
Jenkins のテストも即座に実行されることが確認できる。
【2013-10-29 加筆 (start ---) 】
補足2:Jenkins でテストが失敗した時に、任意のアドレスにメールを送信したい。
テストが失敗した時に、メールで通知するようにするために、
まずメールサーバーの構築が必要になる。
すでに、送信用の用途で用意された SMTP サーバーを持っているならばそれを使えばいい。
今回の用途としては、「テスト失敗時に Jenkins がメールを送信する」だけの用途なので、
Postfix をカスタマイズなしで使うのでも十分な感じがする。
Postfix をサーバーにインストールする。
Jenkins をインストールしているサーバーと、同じサーバーに Postfix をインストールする。
Postfix に関する詳細な説明は省いて、必要な操作だけ記す。
まず Postfix との競合を避けるために、sendmail が動いていないか確認し、動作していれば止めよう。
# sendmail の動作確認 $ chkconfig | grep sendmail # sendmail の停止 $ sudo chkconfig sendmail off $ sudo /etc/rc.d/init.d/sendmail stop
Postfix のインストール。
$ yum install postfix
サーバーが利用する MTA を、Sendmail → Postfix へ切り替える。
$ sudo alternatives --set mta /usr/sbin/sendmail.postfix
今回のように、Jenkins から一方的にメールを送るだけでよければ、
Postfix の設定ファイル( /etc/postfix/main.cf )の変更は特に必要ない。
このまま、Postfix の起動と、サーバーリブート時の自動起動設定を行おう。
# Postfix の起動 $ sudo postfix start # Postfix のリブート時の自動起動設定 $ sudo chkconfig postfix on
以上で、メールサーバーの構築は完了。
テスト失敗時に、メールで通知するようにする。
Jenkins を開いて、まず全体の設定を行う。
- 「ダッシュボード」→「Jenkinsの管理」→「システム設定」
- 「E-mail 通知」を設定する
- ローカルに Postfix をインストールした人は、SMTPサーバーを「空欄」のまま。「返信先アドレス」だけ、何か有効なメールアドレス(例えばあなたのメールアドレス)にしておいて下さい。
- 外部の SMTP サーバーを使う人は、ここにその情報を入力します。(例:Jenkinsでビルド失敗時にGmailで通知する )
ローカルの Postfix を使っているならば、↑ のようにシンプルな設定内容となる。
これで、全体の設定は OK なので、
今度はプロジェクト毎の、通知設定を行う。
- 「ダッシュボード」→「任意のプロジェクトを開く」
- 「設定」
- 「ビルド後の処理」の項目の「ビルド後の処理の追加」をクリック。→「E-mail通知」
- 「E-mail通知」
- 「宛先」に、テスト失敗時にメールを送信したいアドレスを入力して下さい。
- 「保存」をクリック
↑ こんな感じになるはず。
この状態で、試しにビルドを失敗してみて下さい。
「ビルドを失敗した時」と、その「ビルドの失敗から回復した時」に、メール通知されるのが確認できる。
【2013-10-29 加筆 (--- end) 】
最後に。
長々とありがとうございました。
Jenkins の設定は、未熟な私には骨が折れました...。
Jenkins を設定しなければいけなくなった皆さんと、将来の自分のためにこの備忘録をお役立て下さい。