【Jenkinsとは？】インストール〜使い方〜自動テスト・自動デプロイまで世界一分かりやすく解説します

本記事を作成することになったきっかけ

フリーランスエンジニアとしてJenkinsを利用した案件に参画中なのですが、勉強がてらQiita記事にして知見を広めよう！ということで、書くことにしました。
また、この記事は書きかけですが、随時更新予定です。
https://www.udemy.com/course/jenkins-from-zero-to-hero/learn/lecture/19367702
のudemyの動画で学びつつ、調べながら記述しているので、間違いがあれば指摘いただけると大変嬉しいです。

対象の読者

仕事でJenkinsを使うことになったが使い方がさっぱり分からない人
Jenkinsってなに？って人
mac利用者

Jenkinsとは？

CIツールです

CIツールとは？

CIはContinuous Integrationの略で、直訳すると継続的統合です。
継続的インテグレーションと呼ばれたりもします。基本情報処理技術者試験を受けたことがある人は、ワードだけは見たことがあるかも知れませんね。

最近よく見るようになったCircleCIも、CIツールの一つです。ちなみに、Jenkinsでできることは全てCircleCIでできると言われています。

しかし、Jenkinsを利用している会社はまだまだ多いはずなので、Jenkinsの知見を得ることは現時点ではサンクコストにはならないと考えています。

コミット→ビルド→テストの自動化できる部分を自動化して効率的に行うことで、開発スピードおよびソフトウェアの品質を保とうというのが、CIツールの狙いです。

ちなみに関連したワードとしてよく出てくるCDは継続的デプロイの略で、CIの上位互換な考え方です。
コミット→ビルド→テストだけでなく、その後のリリース→デプロイも自動化して効率的に開発を行います。

Jenkinsのメリット

Jenkinsを使うと、ビルドとテストを自動化することができます。
そして、ビルドやテストに失敗したとき、Jenkinsで即座に確認することができるので、不具合の早期発見に繋げることができ、ソフトウェアの品質の向上に役立てることができます。

Jenkinsのデメリット

Jenkinsの習得コスト、およびJenkinsの環境を構築するのに工数がかかります。現在はCircleCIへ乗り換える企業さんも多いようなので、学んだことが無駄になる可能性もあります。

Jenkinsのインストール方法

Homebrewを利用してインストールします。
Homebrewは、ソフトウェアをインストールしたり、インストールしたソフトウェアを管理するためのソフトウェアです。
macを利用している方であれば全員インストールしているかと思いますが、もしまだインストールしていなければ、下記コマンドをterminalに打ち込んでインストールします。

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

※もしインストールできなかったら
コマンドが古い可能性があります。Homebrewの公式ホームページに最新のインストール用コマンドが載っているので参照します。
https://brew.sh/index_ja

続いて、terminalでHomebrewを利用してjenkinsをインストールするコマンドを入力します。(少し時間かかります)

brew install jenkins

インストールが終わったら、terminalでjenkinsを起動するコマンドを入力します。(よく利用するコマンドなので僕はclipyに登録しています)

launchctl start homebrew.mxcl.jenkins

これでjenkinsが起動したので、ブラウザを開いて「localhost:8080」を入力します。jenkinsはhttpサーバーなので、ポート番号8080でアクセスしています。

しばらくすると下記画面になります。

赤文字で示されたパスにパスワード置いたのでそれ入力してねって言われてます。terminalで下記のようにするとパスワード表示されます。

cat 赤文字で表示されてるパス

パスワード入力後、下記画面になります。

推奨されたプラグインをインストールするか、プラグインを選択してインストールするか尋ねられています。左を選択すると、下記画面になり、推奨されたプラグインのインストールが始まります。

インストールが終わると、下記画面になります。
全て入力して、右下のsave and continueを押します。
入力したものは、jenkinsへのログインに使用するので忘れないようにします。

入力が終わると、下記画面になります。
「URL変えますか？」って聞かれてるので、お好みで変更します。
僕は勉強用に使用しているので特に変更していません。
save and Finishをクリックします。

下記画面になるのでstart using jenkinsをクリックします。

下記画面が表示されたら、jenkinsのインストール完了です。

Jenkinsの終了方法

インストール途中、下記コマンドでJenkinsを起動したと思います。

launchctl start homebrew.mxcl.jenkins

起動したあと、terminalで終了コマンドを入力してあげないと起動しっぱなしになるので、下記コマンドをterminalで入力して終了します。(よく利用するコマンドなので僕はclipyに登録しています)

launchctl stop homebrew.mxcl.jenkins

使い終わったら終了してあげます。

Jenkinsの完全アンインストール方法

brewでjenkinsをインストールしたので、アンインストールもbrewで行います。下記コマンドをterminalで入力するとアンインストールされます。

brew uninstall jenkins

しかし、それだけではJenkins起動時に設定したユーザー名とかパスワードとか各種データが残るので、再度jenkinsをインストールした時にそれらの情報を利用してログインすることになります。それも消したい場合は下記のようなコマンドをterminalで入力することで、完全に削除することができます。
Usersディレクトリ配下にユーザー名ディレクトリがあり、更にその配下に.jenkinsディレクトリがあるので、それをrm -rfコマンドで削除します。(パスは人それぞれ違うので読み替えてね)

cd /Users/ユーザー名/.jenkins
cd ../
rm -rf .jenkins

2020/09/02

Jenkinsをためしに動かしてみよう

Jenkinsには、ジョブという概念があります。
ここでいうジョブとは、一定の手順を自動化したもののひとまとまりのことです。
1つ作ってみると理解が進むと思いますので、さっそくジョブを作成してみます。

下記画面で、新規ジョブ作成をクリックします。

ジョブ作成画面に移りました。

Enter an item nameは、ジョブ名を表します。
好きな名前を入力します。

好きな名前を入力したら、フリースタイル・プロジェクトのビルドを選択します。
少し古めのツールなので、UIの操作に少し癖があります。

[Tips]
フリースタイル・プロジェクトのビルドは、一番ベーシックなジョブを作成することができます。
任意のSCM(source code manager:githubとかsubversionとか)からソースコードを
取ってきて、任意のビルドシステムでプロジェクトをビルドすることができます。
その他にも、様々な任意の自動化に利用することができます。
他の項目が何なのかまだよく分かっていないので、説明はまた後日します。
今回はテスト用なので、このフリースタイル・プロジェクトで
「私はJenkinsで一番最初のジョブです」
と表示するシェルスクリプトを実行します。

左下のOKをクリックすると、以下の画面になります。

様々な設定がありますが、今回やりたいのはシェルスクリプトを使って文字列を表示することです。なのでほとんどの設定は使いません。

下のほうにスクロールすると、ビルドという項目があるので、ビルド手順の追加からシェルの実行を選択します。

そうすると、シェルのコマンドを入力するフォームが現れるので、下記を入力します。

echo "私はJenkinsで一番最初のジョブです"

入力できたら、保存をクリックします。

これで、初めてのジョブが作成できました。
続けて、左側のメニューにあるビルド実行をクリックします。
この操作を、「ジョブをビルドする」と言います。

ジョブをビルドすると、ビルド履歴に、●#1というのが作成されました。
これは、ビルド結果を表します。
●の意味ですが、●(青色)だとビルド成功で、●(赤色)だとビルド失敗を表します。途中でビルドをキャンセルしたりすると、●(灰色)になります。
#1がリンクになっているのでクリックします。

そうすると、ビルド時間が確認できたり、そのビルド結果に対して左側のメニューで色々確認することができます。
ビルド時の詳細な情報は「コンソール出力」で確認できるので、クリックして開きます。

これは、ジョブをビルドした時のログを表示しています。
下から2行目で「私はJenkinsで一番最初のジョブです」と表示されています。
つまり、先ほどフォームに入力したシェルスクリプトの実行に成功したことが確認できます。

実際に自動ビルドしたり自動テストしたりするときはもう少し複雑な設定が必要ですが、これがジョブを作る時の大まかな流れです。

左上のJenkinsのバナーをクリックするとトップページに戻ることができます。

ジョブが作成され、表示が変更されたことが確認できます。
先ほど作成したジョブのジョブ名が表示されています。
その左にはSとWが確認できます。

Sは、色のついた●が表示されています。最終ビルド結果を表します。
●は成功
●は失敗
●は未実行またはキャンセル

Wは、最新の何件が成功だったかを知ることができます。
は全て成功です
は少し成功です
は全て失敗です

作ったジョブを編集してみよう

作ったジョブは、編集することができます。
シェルスクリプトで文字列を表示しましたが、今度は日付を表示するシェルコマンドdateと、自分のユーザー名を知ることのできるwhoamiコマンドを使ってみましょう

トップページからジョブを選択し、左のメニューバーの設定をクリックします。

シェルスクリプトを、以下のように書き換えます。

修正前

echo "私はJenkinsで一番最初のジョブです"

修正後

echo "$(whoami)さんこんにちは！今日の日付と時間は$(date)です"

書き換えたら保存をクリックしてビルドを実行し、最新のビルド結果からコンソール出力を開いてみます。

ジョブを編集できたことが確認できます。

Jenkinsでジョブを実行すると、どのディレクトリで実行されるの？

macにJenkinsをインストールした場合は、以下のディレクトリでジョブが実行されます。

/Users/ユーザー名/.jenkins/workspace/シェルで文字を出力するジョブ

ジョブのシェルスクリプトで現在のディレクトリを表示するpwdコマンドを実行すると、このディレクトリが表示されます。

AWSのEC2のAmazon LinuxにJenkinsを構築したり、VirtualBoxのLinuxにJenkinsを構築した場合は、また違ってきます。分からなくなったら、ジョブでpwdを実行するシェルスクリプトを作成してビルドすると確認することができます。

また、macでは.jenkinsディレクトリ以下は隠しフォルダになっているので、finderで表示する場合は隠しフォルダを表示する設定にする必要があります。

Jenkinsのジョブデータはどこに保存されるの？

macにJenkinsをインストールした場合は、以下のディレクトリにジョブのデータが格納されます。

/Users/ユーザー名/.jenkins/jobs/シェルで文字を出力するジョブ

ここからログを直接取得したりすることなどできます。
色々弄るとJenkinsがジョブデータを読み込めずにバグっちゃう可能性があるので慣れないうちは弄らないほうがいいです。(経験談)

Jenkinsでジョブのビルドに失敗してみよう

ここまでは成功パターンしか無かったので、わざと失敗してみます。
ジョブを選択し、設定からシェルスクリプトを入力する画面まで移動します。

末尾の"を消します。

修正前

echo "$(whoami)さんこんにちは！今日の日付と時間は$(date)です"

修正後

echo "$(whoami)さんこんにちは！今日の日付と時間は$(date)です

保存をクリックし、ビルド実行をクリックします。

ビルド履歴が赤くなったことが確認できます。つまり、ビルドに失敗しました。
今回の場合なぜビルドに失敗したのか分かりきっていますが、なぜビルドに失敗したのか確認します。
ビルド履歴から赤くなったリンクを辿り、コンソール出力をクリックします。

ログから、以下の情報を読み取ることができます

どの行でエラーが出ている

/var/folders/sp/s32xwxcx69343zl_szqw02kw0000gn/T/jenkins13410237169821088770.sh: line 2: unexpected EOF while looking for matching `"'

なぜエラーとなったのか

Build step 'シェルの実行' marked build as failure

結果が失敗していること

Finished: FAILURE

ビルドに失敗したときは、まずはコンソール出力を確認することで、原因の究明に役立ちます。

シェルスクリプトで末尾に"がないので、元に戻して再度ビルド実行します。

修正前

echo "$(whoami)さんこんにちは！今日の日付と時間は$(date)です

修正後

echo "$(whoami)さんこんにちは！今日の日付と時間は$(date)です"

これで、ビルドに失敗していたものが再度ビルドに成功するようになりました。

Jenkinsから作成済のシェルスクリプトを呼び出すジョブを作成しよう

ここまでは直にシェルスクリプトをJenkins上で書いていましたが、今度は作成済のシェルスクリプトを呼び出す形にしてみましょう。

「でもどこにシェルスクリプトを置くの？」

Jenkinsにはワークスペースという概念があります。そのワークスペースに置いたものをJenkinsで読み取ることができます。
安心してください、このあとの手順で全て解説します。

「なんでシェルスクリプトを呼び出す必要があるの？」

この手順を覚えておくことで、ワークスペースを活用することができるようになり、応用が効くようになるためです。

さっそく、新規ジョブを作成します。

ジョブ名を「シェルスクリプトを呼び出すジョブ」にし、フリースタイル・プロジェクトのビルドにしてOKをクリックします。

ビルド手順の追加→シェルの実行をクリックし、保存をクリックします。

この時点ではシェルスクリプトのフォームは空で問題ありません。

ワークスペースをクリックします。
左側のメニューに表示されているものと、右側に表示されているもののどちらをクリックしても同じページに飛びます。

迷ったらクラピカ理論で選択してください。

レオリオ「なんでだよフツーこういうときは左だろ？
        つーかオレはこんな場合左じゃねーとなんか落ち着かねーんだよ」

クラピカ「たしかに行動学の見地からも　人は迷ったり未知の道を選ぶ時には
        無意識に左を選択するケースが多いらしい」

ワークスペースを開くと、ワークスペースが存在しないことが確認できます。
エラーと書かれていますが、これは正常動作です。

シェルスクリプトをワークスペースに置くことでJenkinsから実行することができるようになるのですが、一度ビルドしないとワークスペースは作成されない仕様となっています。

というわけで一度ビルド実行してから再度ワークスペースを開きます。

上記のような画面になっていれば、ワークスペースが作成されています。

んで、このワークスペースはどこにあるか？

/Users/ユーザー名/.jenkins/workspace/シェルスクリプトを呼び出すジョブ

にあります。

色々試しましたが、Jenkinsからはスクリプトファイルが置けなかったので、Finderから上記パスにシェルスクリプトを作成しに行きます。(Jenkinsからやれるかどうか分かっていないのでこのやり方で説明します)

上記ワークスペースにscript.shファイルを作成し、中身を以下のように記述します。

script.sh

# 利用しているシェルの種類を出力します
echo "(利用しているシェルは「 $SHELL 」です)"

# 名前を表示します
LASTNAME=$1 # 1つ目の引数に名前を渡します
FIRSTNAME=$2 # 2つ目の引数に名字を渡します
NAME=$FIRSTNAME$LASTNAME # 名字と名前をくっつけます
echo "こんにちは、$NAME さん"

このシェルスクリプトは、使用しているシェルと、引数を元に名前を出力してくれるものです。

作成し終わったら、Jenkinsでの操作に戻ります。

Jenkins上でも、script.shの存在が確認することができます。
表示されてなかったらページを更新すると確認できます。
それでも表示されていなかったら、シェルスクリプトを作成するディレクトリに誤りがあります。

ジョブの設定をクリックします。

以下を入力します。

sh script.sh りゅうけん やまもと

これは、shというシェルで、script.shに、第一引数「りゅうけん」、第二引数「やまもと」を渡して実行するという意味です。

入力したら保存をクリックし、ビルド実行をクリックします。

ビルド履歴が●になっていたら成功です。
最新のビルド履歴をクリックし、コンソール出力をクリックします。

(利用しているシェルは「 /bin/zsh 」です)
こんにちは、やまもとりゅうけん さん

と表示されていたら、成功です。

これで、ワークスペースに置いたスクリプトを実行するジョブを作成することができました。

この章はここで終わってもいいですが、シェルスクリプトに慣れるために、Jenkinsのシェルスクリプトを改造して、変数を作成してからscript.shに渡してみましょう。

ジョブから設定を開き、以下のようにします。

修正前

sh script.sh りゅうけん やまもと

修正後

FIRSTNAME=やまもと
LASTNAME=りゅうけん
sh script.sh $LASTNAME $FIRSTNAME

※注意

FIRSTNAME=やまもと
LASTNAME=りゅうけん
sh script.sh $LASTNAME $FIRSTNAME

を、

FIRSTNAME= やまもと
LASTNAME= りゅうけん
sh script.sh $LASTNAME $FIRSTNAME

と=のあとにスペースを入れたりしてしまうとジョブのビルドに失敗します。

保存をクリックしてビルド実行し、最新のビルド履歴を開いてコンソール出力を見てみましょう。

同様の結果となります。

Jenkinsのビルドのパラメータ化を活用しよう

さんざん無視してきましたが、ここで初めてオプションの1つである「ビルドのパラメータ化」を使ってみたいと思います。

今、シェルスクリプトではFIRSTNAMEとLASTNAMEの変数を用意し、値をセットして利用しています。

これらをビルドのパラメータ化します。
ビルドのパラメータ化にチェックを入れます。

続いて、パラメータの追加から文字列を選択します。

すると、名前、デフォルト値、説明を入力する欄が出てきました。

名前にFIRSTNAME、デフォルト値にやまもと、説明に名字ですと入力します。

これで、1つの変数をビルドのパラメータ化することができました。
続いて、もう一つ作成します。

もう一度パラメータの追加から文字列を選択します。

名前にLASTNAME、デフォルト値にりゅうけん、説明に名前ですと入力します。

これで、2つの変数をビルドのパラメータ化することができました。

最後に、Jenkinsのシェルスクリプトから不要になった記述を削除し、以下のように書き換えます。

修正前

FIRSTNAME=やまもと
LASTNAME=りゅうけん
sh script.sh $LASTNAME $FIRSTNAME

修正後

sh script.sh $LASTNAME $FIRSTNAME

これでシェルスクリプトがスッキリしました。
これだけでもメリットのように感じますが、メリットなのはこれだけではありません。
ここからが本当のビルドのパラメータ化のメリットです。保存をクリックしましょう。

ここで、一つ表示が変わったことに気が付きます。
今までビルド実行となっていた部分が、パラメータ付きビルドに変化しています。

さっそくクリックしてみましょう。

ビルド実行をクリックしていたときはすぐにビルド実行が始まりましたが、ビルドのパラメータ化を設定することによって、ビルド実行前に変数の値を変更することができるようになりました。

一度、そのままビルドをクリックし、終わったら最新のビルド履歴からコンソール出力を開きます。

表示される文字列は先ほどの章と変わっていません。
続いて、プロジェクトへ戻る→パラメータ付きビルドと辿ります。
今度は名字をかつまた、名前をけんたにします。

ビルドをクリックし、終わったら最新のビルド履歴からコンソール出力を開きます。

表示される名前が変化したことが確認できます。
ビルドのパラメータ化を設定することで、ビルド実行ごとに変数を変化させることができるようになりました。
デフォルト値も設定できますし、ビルド実行ごとに変数を変化させる必要がある場合は活用できそうな機能です。

ビルドのパラメータの使い方は無限大です。この章ではビルドのパラメータ化が色々と活用できそうであることが伝わればOKです。

Jenkinsのビルドのパラメータ化を選択式にしよう

ビルドのパラメータ化は文字列を入力するだけでなく、選択式にすることも可能です。
ビルドのパラメータ化を一度全てまっさらにします。

続いて、パラメータの追加の選択を選択します。

以下の画像に合わせて、名字と名前を選択式にするための設定をします。
名字は「やまもと」「かつまた」「ばんない」から選択できるようになります。
名前も同様に作成し、「りゅうけん」「けんた」「まなぶ」から選択できるようになります。

保存をクリックし、パラメータつきビルドをクリックします。

名字と名前が選択式になっていることが確認できました。
名字を「ばんない」、名前を「まなぶ」にします。

cool。(外国人講師の真似)

続いてビルドをクリックし、ビルド履歴の最新からコンソール出力をクリックします。

選択した名前「ばんない」「まなぶ」と表示されることが確認できました。
余談ですがマナブさんは僕と同い年で生まれは4ヶ月差です。

これで、ビルドのパラメータ化を選択式にすることができました。

Jenkinsのビルドのパラメータ化を使って表示・非表示を切り替えよう

今までどのシェルを利用していたかを表示するようにしていましたが、毎回表示する必要も無いということで、ビルドのパラメータ化を使用して、表示・非表示を切り替えるようにします。

ジョブの設定から、パラメータの追加で真偽値を選択します。

名前をSHOWSHELL、デフォルトは非表示にしたいのでチェックなし、説明はチェックすると使用しているシェルを表示することができます。とします。

保存をクリックします。

続いて、ワークスペースに置いてあったscript.shを、SHOWSHELLがtrue(1)ならシェルを表示し、false(0)ならシェルを表示しないように書き換えます。

修正前

/Users/ユーザー名/.jenkins/workspace/シェルで文字を出力するジョブ/script.sh

# 利用しているシェルの種類を出力します
echo "(利用しているシェルは「 $SHELL 」です)"

# 名前を表示します
LASTNAME=$1 # 1つ目の引数に名前を渡します
FIRSTNAME=$2 # 2つ目の引数に名字を渡します
NAME=$FIRSTNAME$LASTNAME # 名字と名前をくっつけます
echo "こんにちは、$NAME さん"

修正後

/Users/ユーザー名/.jenkins/workspace/シェルで文字を出力するジョブ/script.sh

# 変数定義
LASTNAME=$1 # 1つ目の引数に名前を渡します
FIRSTNAME=$2 # 2つ目の引数に名字を渡します
SHOWSHELL=$3 # 3つ目の引数にシェルを出力するかどうかのフラグを渡します

# 利用しているシェルの種類を出力します
if [ "$SHOWSHELL" = "true" ]; then
    echo "(利用しているシェルは「 $SHELL 」です)"
fi

# 名前を表示します
NAME=$FIRSTNAME$LASTNAME # 名字と名前をくっつけます
echo "こんにちは、$NAME さん"

Jenkinsでの操作に戻り、パラメータ付きビルドをクリックします。

今回、使用しているシェルはもう表示しないのでそのままビルドをクリックし、最新のビルド履歴からコンソール出力を表示します。

今まで表示していたシェルの種類が表示されなくなることが確認できました。

これで、ビルドのパラメータ化を使用して表示・非表示を切り替えることができるようになりました。

Jenkinsでrailsアプリケーションの自動テストを行おう

GitHubからrailsアプリケーションを持ってきて、Jenkinsでテストと静的解析を行うジョブを作成します。

railsアプリケーションの作成方法やrubyのバージョンを簡単に書き換えることのできるrbenvとそのrbenvなどをインストールするためのソフトであるHomebrewのインストール方法、自動テストで使用するrspec・静的解析ツールとして使用するrubocopの導入方法は割愛します。
下記GitHubにrspec導入済みおよびrubocop導入済みの個人アプリがあるので、こちらを例に説明します。
https://github.com/EL93019205/stuctive.git
railsは5.2.3、rubyは2.5.1を使用しています。

プラグインを導入している手順を紹介している記事がわんさか出てきますが、プラグインはデフォルトのもの以外一切不要です。プラグインが全体的に古くてあまり使い物にならないなって

それではさっそく新規ジョブを作成しましょう。

ジョブ名はrails
の都合上英語にしなければなりません。今回は「stuctive_auto_test」にします。

ジョブの種類はフリースタイル・プロジェクトのビルドにします。

できたらOKをクリックします。

ソースコード管理という項目があるのでGitにします。
そうすると下記画面になります。

リポジトリURLにGitHubの
さて、リポジトリURLには何を入力したらいいのでしょうか。
答えはGitHubに書いてあります。

下記URL(僕の個人アプリのリポジトリへのURLです)から緑色のボタンのCodeをクリックし、URLの書かれている部分の右のアイコンをクリックします。このアイコンはコピーをすることを表しています。
パブリックリポジトリなので多分誰でもコピーして使えるんじゃないかと思います。
https://github.com/EL93019205/stuctive

そして以下のように「https://github.com/EL93019205/stuctive.git 」をリポジトリURLに貼り付けます。

ソースコード管理の設定はこれだけです。
他に弄る必要はありません。

「え？それだけ？」と思いましたか？
はい、それだけです。

セキュアな設定をしている場合は認証情報を設定したり、自動テスト対象のブランチがmaster以外の場合はビルドするブランチを変更したりする必要あるかと思いますが、僕の個人アプリがパブリックリポジトリで、かつ自動テストを行いたいブランチがmasterなので弄る必要がないのです。

この設定により、workspaceへrailsアプリケーションがクローンされます。

一度保存をクリックします。

ワークスペースを開きます。

ワークスペースが存在しないことが確認できます。

上のほうで書きましたが、ビルド実行を一度行わないとワークスペースは作成されません。
なので、ビルド実行をクリックします。

ビルド履歴が青色になったことが確認できますね。

再度ワークスペースを開きます。

下記のようになっています。
railsアプリケーションを作成したことがある方であれば、見覚えのあるファイル達ばかりではないでしょうか。

このデータは、下記GitHubのデータと全く同じです。
https://github.com/EL93019205/stuctive

このように、めちゃめちゃ簡単にGitHub上のrailsアプリケーションのデータ一式をJenkinsのワークスペースにコピーできちゃうのです。

残るは、この取ってきたデータで自動テストのコマンドを、Gemfileのあるディレクトリで実行するだけですね。
railsのバージョンによって自動テストのコマンドは全く異なるのですが、今回はrails5.2.3を使用しているので、下記コマンドで実行できます。

bundle exec rspec
bundle exec rubocop

これを実行するようにしましょう。

設定を開きます。

一番下までスクロールして、シェルの実行に先ほどのコマンドを貼り付けます。
このコマンドは、workspaceディレクトリで実行されます。つまり、Gemfileのあるディレクトリで実行されるということですね。
終わったら保存をクリックします。

そしてビルド実行します。

おや、ビルド履歴が赤色になりました。
なにが原因だったのでしょう？

●#2をクリックしてコンソール出力を開きましょう。

一番下に下記のエラーログが出ていることが確認できます。

これは、bundle installが必要ということですね。
想定内の動作なので、あえてエラーにしてみました。

なので、設定に戻ってbundle installを書き加えます。

保存してもう一度ビルド実行

またもやエラーになります。
●#3をクリックしてコンソール出力を開きましょう。

rubyのバージョンは2.6.3だが、Gemfileでは2.5.1となっているのでbundle installできないよと怒られます。

ここは人によってそういったエラーが出る・出ないが変わる部分だと思います。また、異なるエラーが出ることもあるかも知れません。なにせPCによって環境が大きく異なるためです。

ここでrbenvのインストールをしたり、Homebrewをインストールしようとしたりするのは悪手です。泥沼にハマりますよ。僕はハマりました。

色々調べた結果、環境変数のPATHが、Jenkinsのビルド実行時に上書きされることによる現象のようです。

Jenkins用の環境変数が使用できる作りになっているので、そうなることもあり得るなという感じです。

なので、ビルド実行後に環境変数PATHをローカルPCのPATHで上書きする作りにしてしまいましょう。

環境変数PATHの調べ方ですが、macのterminalで下記コマンドを実行します。
このコマンドは、printenvコマンドで全ての環境変数一覧を取得したあと、その結果を元に|で繋げてgrepコマンドでPATHの含まれている行のみを表示するためのコマンドです。

printenv | grep PATH

そうすると、環境変数PATHの値が表示されます。

これは人によって異なるのですが、JenkinsではこのPATHを戻してあげる必要があります。

そのため、以下のように書き換えます。

export PATH="先ほどコピーしたPATHの内容を貼り付け"
bundle exec rspec
bundle exec rubocop

僕の場合は下記のようになります。
PATHは人によってそれぞれ異なるため、読み替えてください。

これで保存して再度ビルド実行をクリックします。

ビルド実行に成功しました！

●#4からコンソール出力を開いてログを見てみましょう。

まずはbundle installのログが出ていることが確認できます。

続いて、bundle exec rspecのログが出ていることが確認できます。

最後に、bundle exec rspecのログが出ていることが確認できます。

これで、ビルド実行によってrailsアプリケーションの自動テストを行うジョブを作ることができるようになりました。

ここで、「rubocopやrspecの実行結果によって●にするか●にするか分岐させるためのシェルスクリプトを作成しなければならないのでは？」と思った方もいるかも知れません。

結論から言うと必要ありません。bundle exec rspecとbundle exec rubocopコマンドは、エラーがあるとエラーコードが返るようになっており、Jenkinsはそのエラーコードを見て●にするか●にするか決めてくれています。これは便利！

シェルスクリプトやシェル、grepやprintenvなどのコマンド、環境変数の意味などが分からなかった方は、Linuxの知識が欠けていますので、下記書籍で勉強するといいでしょう。僕もLinuxはさっぱりなのでこれからこの書籍を買って勉強しようと考えています。
https://www.amazon.co.jp/dp/B072K1NH76/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1

今回はここまでにします。

Webhookを用いてリモートリポジトリのトピックブランチへpushすると自動テストが実行される作りとすることができますが、それはまた別の日に紹介したいと思います。

Jenkinsでrailsアプリケーションの自動デプロイを行おう

注意！ここは手順をそのまま真似しても自動デプロイできません。なぜならrailsアプリケーションのmaster.keyを僕が保有しているためです。
また、僕の個人アプリが既にCapistranoでコマンド一発で本番環境にデプロイできるような作りとなっています。その方法は記載していません。難しいですが、一応下記に本番環境構築方法含めてやり方載せています。
https://drive.google.com/drive/folders/14F4AmgnK0n022uYLatlQbvuPIGLGLFgt

やり方だけお見せします。Jenkinsでやることはめちゃめちゃ簡単です。

新規ジョブ作成をクリックします。

ジョブ名を「stuctive_auto_deploy」、ジョブの種類をフリースタイル・プロジェクトにしてOKをクリックします。

ソースコード管理をGitにして、リポジトリURLをhttps://github.com/EL93019205/stuctive.git (僕の個人アプリ)にします。

ビルドのビルド手順の追加からシェルの実行を選択して、シェルスクリプトを下記のようにします。

やっていることは3つです。
・JenkinsのPATHをローカルPCのPATHで上書き(自動テストと同じ)
・master.keyのあるところからワークスペースにmaster.keyをコピーして取得
・Capistranoの自動デプロイコマンドを実行

保存をクリックしてビルド実行をクリックします。

ビルド実行後、ビルド履歴が●#1となります。

●#1をクリックしてコンソール出力をクリックし、自動デプロイ時のログが出ていることを確認します。

これで、ビルド実行によってJenkinsでrailsアプリケーションの自動デプロイを行うことができるようになりました。

多分Webhookを用いてリモートリポジトリのmasterブランチが更新されると自動デプロイが実行される作りとすることができるのですが、そちらはまだ勉強中のため、また別の日に紹介したいと思います。

終わりに

分かりにくい部分ありましたら是非コメントで残していただけると嬉しいです。
最後まで読んでくださり、ありがとうございました。