概要
http://qiita.com/yuichi10/items/8555a51810230fefa73c
の続きです
テストを通してからpcfにデプロイするようにします。
自分で試した参考のコードです
https://github.com/yuichi10/pcf-app/commit/663f5bcfcc98318488cd7bd1eb5f2c20df4427c4
(これからいじることもあるのでリリースタグをつけて起きました)
すること
- テストを書く
- pipelineの書き換え
- test用のymlまたテストを実行するshell scriptの作成
- testしたものをpipelineにあげるbuild.yml build.shの作成
テストを書く
ここの説明は省くので何か適当にテストをかいといてください、、
pipelineにtestをするjobの作成
まずtestを回すjobを書いていきます。前回書いたdeployの上に書いていこうと思います。
---
resources:
...
...
skip_cert_check: true
jobs:
- name: go-test
plan:
- get: repo
trigger: true # repo(get対象)のバージョンの変更がtriggerになる
- task: unit-test # taskの名前
file: repo/ci/unit-test.yml # タスクが実際に書いてあるファイルを指定
- name: deploy
...
タスクの内容までここに書いてしまうと、長くなってしまうのでタスクはファイルを分けて書いていきます。ファイルを指定するためにはtaskのfileにタスクの内容が書かれているファイルを指定します。今回はunite-test.ymlとファイルです。
タスク(unite-test.yml)の作成
テストタスクを実際に書いていきます
---
platform: linux # どのプラットフォームで動かすか
image_resource:
type: docker-image # どのタイプのコンテナイメージを使うか。多分大体docker
source: {repository: concourse/static-golang} # image (今回はconcourseが用意しているdocker imageを選んでます)
inputs:
- name: repo # jobに必要なファイルをinputする(今回は自分のアプリ)
run: # 実行するものを指定
path: ci/unit-test.sh # 実行するファイルを下のdirから相対パスで指定している
dir: repo # runするディレクトリ
linux上にdockerをたててそのなかでテストをしています。今回はci/unit-test.shというタスクを実際に実行しています。ただまだci/unit-test.shは存在していないのでそのファイルを作っていきます。
ci/unit-test.shの作成
実際に走らせるタスクをci/unit-test.shにまとめていきたいと思います。
今回することはテストを走らせることです。
では実際のファイルを書いていきます。
#!/bin/bash
set -eu
dir="/go/src/<go>/<package>/<path>" # ex) /go/src/github.com/yuichi10/pcf-app
mkdir -p $dir
cp -r ./* $dir
pushd $dir
go test ./...
popd
今回用意した実行のシェルスクリプトです。goの場合packageの問題から少しややこしいことをしています。mkdir -p $dir から解説していきます。
- まずpackageの通りのディレクトリを作ります。
- 作ったディレクトリに自身のアプリのソースをコピーします。
- 作ったディレクトリに移動します
- 実際にテストを実行しています。
- 元の場所に戻ってます
これでテストを走らせる準備ができました。
ただこれではまだテストを通した後にpcfにpushすることができません。
次はテストを終わらせたらdeployrが走るようにしていきます。
実行できるように権限を追加しておいてください!!!
chmod 755 ci/unit-test.sh
testが終わったらdeployさせる
まずpipelineでtestがpassしたら走らせるということを書いていきます
パイプラインの更新
---
resources:
...
skip_cert_check: true
jobs:
- name: go-test
...
file: repo/ci/unit-test.yml
- name: deploy
serial: true
plan:
- get: repo
passed: [go-test]
trigger: true
- task: prepare-build
file: repo/ci/build.yml
- put: pcf
params:
manifest: out/manifest.yml
path: out
大きな変更点のひとつはdeployのplanのgetにpassedが追加されたことです。このpassedで他のjobを指定して、そのjobがパスしたら という条件を加えることができます。
またtaskがないと走らなかったため、taskを追加しています。(理由がまだわかってないです)
最後にputのparamsでpathにoutを指定しています。ここに関しては後からなぜoutになったかわかると思います。
さてここでもgo-testと同じようにタスクでファイル(build.yml)を指定しています。なのでそのファイルについてみていきます
build.ymlについて
---
platform: linux
image_resource:
type: docker-image
source: {repository: concourse/static-golang}
inputs:
- name: repo
outputs:
- name: out
run:
path: ci/build.sh
dir: repo
args:
- ../out
先ほどのunit-test.ymlとの違いはoutputsがあることと、runにargsというものが追加されていることです。
まずoutputsは名前の通りアウトプットするものを指定しています。
argsではそのアウトプットにつかうoutを指定しています。ここでargsにあたえると自動で../outのディレクトリを作ります。またci/build.shの引数にもなっています。
つまりこのファイルでは、linux上にdockerをたててci/build.shを実行しておりそのときの引数に ../out を与えています。そしてその結果をoutputでだしています。
さてここでさっきでてきたoutが出てきました。そうです、pipelineで指定したoutはこのぶbuild.ymlのoutをさしています。
ではci/build.shが何をしているかみてみます。
bi/build.shについて
ここはほぼなにもしてないのでこーどをみればわかると思います。
#!/bin/bash
set -eu
shopt -s dotglob
# glide install
cp -r ./* $PWD/$1
はい自身のコードをoutにコピーしているだけです。先ほども言ったようにargsで指定したものは引数となっているので$1で取得することができます。
後これだけでは味気ないので実際にはglide install とかをここでするという意味も込めてコメントで書いています。
実行できるように権限を追加しておいてください!!!
chmod 755 ci/build.sh
これで全部の工程が終わりました。
実際に回す
まずパイプライを更新したのでset-pieplineをします
fly -t <target> set-pipeline -p <コンコースの名前> -c ci/pipeline.yml -l ci/credential.yml
これでコンコースのパイプラインが更新されました。
次に今回のコードをgithubに上げてください。
これで準備が終わりました。コンコースのUIのページ(defalut: http://127.0.0.1:8080/) にいって自身が指定したコンコースの名前のものを選択してください。
この画像のように前よりちょっとリッチになってるのではないでしょうか。
そしたらgo-testを押してもらって+ボタンをおして実行してみてください。go-testが終わったら自動でdeployが走るのも見れると思います。
pipelineをpauseしていたらunpauseするのを忘れないでください。
今回はここまでです。