【入門】Jenkins (CI) + Ruby on Rails 3.2.x (RSpec) + GitHub + Amazon EC2 (Amazon Linux AMI) を使った継続的テスト【更新:2013-10-29】

前置き

最近、扱っている Rails アプリケーションの規模が少し大きくなってきたので、
そろそろちゃんとテストを書かないとなぁと思っていた。

私はテスト (CI) に関して次のような考えを持っている。


テストの実行は第三者がおこなう

人はどうしても怠惰な方に流されやすい生き物だと思う。
私も「ちゃんとしっかりテスト(書いて・実行)しよう!」という意思が薄いタイプの人間に思える。
なので、テストの実行と、失敗時の通知は、自分ではない「第三者」がやってくれないと困る。

サボってたら叱ってくれる人がいてほしい。


テストの成功・失敗の履歴は残しておくべき

テストがチェックインごとに正しく実行され、どのチェックインでテストが壊れたのか。
それはきちんと管理されているのが望ましいと思う。

いつの間にか、テストが壊れており、どのチェックインで壊れたのかわからない。
という状況は避けたい。




というわけで Jenkins (CI) を導入することにした。




構成について

今回、下記のような構成のテスト環境をつくった。
この記事では、その環境構築の流れを説明しようと思う。

Jenkins の構築と運用は、今回はじめてイチから行ったので、
いくらか不明確な部分や、誤り、非効率なところを含んでいると思う。
Jenkins の運用に慣れてきたら、いずれ書きなおす予定。


MySQL データベースサーバーは、別インスタンスに事前に準備されていると仮定してすすめる。


話は少し変わって、「Travis CI」という継続インテグレーションサービスがある。

https://travis-ci.org/

GitHub の Public リポジトリにチェックインしているコードならば、この「Travis CI」を先に検討したほうが良いと思う。
Jenkins の環境構築と、メンテナンスを自分でやらなくてすむ。
Private リポジトリに対しても「Travis CI」を使うことはできるが、値段が高い → http://travisci.com/plans

自分で Jenkins サーバーを立てる機会は、まだまだあると思う。



参考記事

Jenkins 入門・セットアップに関する記事を、いくつか読んでみたが、
私は下記の2つの記事が、特に役立った。

ステップバイステップ1:EC2 インスタンスを準備する

この項の目的は、下記の通り。

  • Jenkins のインストール前に必要な、EC2 インスタンスのセットアップを行う。
EC2 インスタンスを Launch
  • AWS から「AWS Management Console」へ移動する
  • 「EC2」→「Instance」→「Launch Instance」→「Classic Wizard」→
  • Amazon Linux AMI 2013.03.1 (64bit) 」→ 「M1 Small」→
    • 「Security Group」は次のポートを開放しておく
      • 8080 (Jenkins の Web Console へ 8080 ポートでアクセスするため)
      • 22 (SSH)
      • 80, 443 (HTTP, HTTPS)
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
  • 保存 or 適用

画面をリロードすると、認証処理が動くようになるため「ログイン画面」が表示される。
先ほどのユーザー追加では、ユーザーの「権限情報の設定」のみを行っただけで、
実ユーザー情報「admin」と「github」はまだ作成されていない。

下記の手順で「admin」と「github」ユーザーを作成(サインアップ)する。

  • ログイン画面の「メンバーでない人は、アカウントを登録してください」をクリック
    • 「admin」というユーザーを作成する
      • 作成できたらログアウト
    • github」というユーザーを作成する
      • 作成できたらログアウト


「admin」と「github」を無事作成できたら、サインアップ処理は一旦不要な機能となる。
この状態のままでは、匿名の誰かが自由勝手にユーザーをサインアップできてしまうのでサインアップ処理を禁止しよう。

  • 「admin」でログイン
  • 「Jenkinsの管理」→ 「グローバルセキュリティの設定」
  • 「セキュリティを有効化」→「ユーザー情報」→「Jenkinsのユーザーデータベース」
  • 「ユーザーにサインアップを許可」を OFF
  • 適用 / 保存

次に Jenkins にいくつかのプラグインをインストールする。
今回、RSpec テストの実行と、Git の操作が含まれていることから次のプラグインインストールを推奨。

  • Publish Over SSH
  • Jenkins SSH plugin
  • Jenkins GIT plugin

プラグインのインストール方法は、次の通り。

  • 「Jenkinsの管理」→ 「プラグインの管理」→「利用可能」
    • 「Git Plugin」 を検索し、チェックを入れる
    • SSH plugin」を検索し、チェックを入れる
    • 「Publish Over SSH Plugin」を検索し、チェックを入れる
  • 「再起動せずにインストール」をクリック
  • 「インストール完了後、ジョブがなければJenkinsを再起動する」をクリック

これでプラグインのインストールは完了。



次に、テストを実行するための Jenkins 上のプロジェクトを作成する。
今回テストを Jenkins に実行させたいプロジェクトを、仮に「example」プロジェクトとする。
GitHub 上にも「https://github.com/komiyak/example」というプロジェクトが、すでに作成済みであるとする。

  • 「Jenkins」→「新規ジョブ作成」
    • ジョブ名は「example」
    • 「フリースタイル・プロジェクトのビルド」を ON
    • OK

プロジェクトの設定は以下の通り

  • プロジェクト単位でユーザーに権限を与える
    • 「権限設定(プロジェクト単位)の有効化」を ON
      • "admin" ユーザーを追加
      • 「全て」を ON にする
      • "github" ユーザーを追加
      • 「Read」と「Build」を 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 にはこの公開鍵を設定するやり方が、どうやら二通りある。

  1. Account Settings」→「SSH Keys」→「Add SSH Key」
  2. 「任意のリポジトリ」→「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 のプロジェクトに設定を行おう。

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 を、SendmailPostfix へ切り替える。

$ 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 を設定しなければいけなくなった皆さんと、将来の自分のためにこの備忘録をお役立て下さい。