콘서트에서 pcf 디버깅 (2)

개요
http://qiita.com/yuichi10/items/8555a51810230fefa73c
계속
테스트를 통과한 후 pcf 테스트를 진행합니다.
이것은 자신이 시험해 본 참고 코드이다
https://github.com/yuichi10/pcf-app/commit/663f5bcfcc98318488cd7bd1eb5f2c20df4427c4
(앞으로 할 일이 있어서 배급표를 붙이고 일어난다)
할 일

쓰기 테스트

pipeline의 개작

test에 사용되는 yml 및 테스트를 수행하는 셸 스크립트 제작

테스트에서 만든 것을 피플라인의build에 주십시오.yml build.sh의 제작시험을 쓰다
여기 설명이 생략되었으니 적당히 테스트해 보시오
pipeline에서 테스트를 하는job의 제작입니다.
우선 테스트의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 파일에 작업 내용이 적힌 파일을 지정하십시오.이번에는 유닛-테스트.파일 및 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

이번에 준비한 조개 각본입니다.goo의 경우 패키지 문제가 좀 복잡해서요.mkdir-P 달러 dir부터 설명합니다.
1. 우선 패키지와 같은 카탈로그를 만든다.
2. 자신의 응용 프로그램의 원본 파일을 만든 디렉터리에 복사합니다.
3. 만든 디렉토리로 이동
4. 실제 테스트를 진행한다.
5. 원래 있던 곳으로 돌아왔다
이렇게 하면 시험을 볼 준비가 다 되었다.
다만 이렇게 되면 테스트를 통과한 후push에서pcf에 올라갈 수 없다.
다음 시험 끝나고 deployr 뛸 거예요.
수행할 수 있도록 권한을 추가하십시오!!!

chmod 755 ci/unit-test.sh

테스트 끝나고 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을 지정합니다.여기에 관해서는 나중에 왜 아웃인지 알게 될 것 같아요.
그러면 여기도 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

아까 유닛 test.yml와의 차이점은 아웃풋스와run에 ARgs가 추가되었다는 점이다.
우선 outputs는 이름에 따라 출력을 지정합니다.
args가 출력에 사용할 out을 지정했습니다.여기서 ARGS에게 자동으로.out 디렉토리를 만듭니다.ci/build.이것도sh의 매개 변수입니다.
즉, 이 파일은 linux에 docker를 설정하고ci/build에 있습니다.sh를 실행할 때의 매개 변수아웃을 주고.그리고 아웃풋에서 그 결과가 나왔어요.
아까 나온 아웃 여기서 나왔어.네, pipeline이 지정한 out은 이build입니다.yml의 아웃을 가리킨다.
그럼 ci/build.쉬가 뭘 하는지 볼게요.
bi/build.sh 정보
여긴 거의 아무것도 안 했어, 이것 좀 보면 알 수 있어.

#!/bin/bash

set -eu
shopt -s dotglob

# glide install
cp -r ./* $PWD/$1

네, 저는 단지 제 코드를 아웃으로 복사했을 뿐입니다.방금 말한 바와 같이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/에서 자신이 지정한 전공 과정의 이름을 선택하십시오.

이 그림처럼 예전보다 조금 부유해졌죠.
그리고 goo-test를 누르고 + 버튼을 눌러 실행하세요.go-test가 끝나면 자동 deploy도 볼 수 있을 것 같아요.
파우스가 pipeline unpause를 만들면 잊지 마세요.
이번엔 여기까지.