概要

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するのを忘れないでください。

今回はここまでです。