GitLab Runner: GitLabでコミットを検知してGitLab Runnerがジョブを実行、ジョブの結果がGitLabから確認できる
### Shared RunnersとSpecific Runners
Shared Runnersはプロジェクトを跨いで共有、Specific Runnerはプロジェクトに紐づけて専用利用
### Executer
ジョブの実行形式
Shell, Docker, Docker Machine, Parallels, VirtualBox, SSH, Kubernetes
-> shellであればGitLab Runnerがインストールされたホスト上でBash等のShellベースでジョブを実行
### パイプライン
パイプライン方式でジョブを実行する
image: python:3.6.5
variables:
S3_BUCKET: デプロイに使うS3バケット
AWS_DEFAULT_REGION: ap-northeast-1
unittest:
stage: test
script:
- pip install pytest
- pip install -r requirements.txt
- python -m pytest tests/ -v
deploy:
stage: deploy
script:
- pip install awscli
- pip install -r requirements.txt -t hello_world/build/
- cd hello_world/*.py hello_world/build/
- aws cloudformation package --template-file template.yaml --output-template-file output.yaml --s3-bucket ${S3_BUCKET}
- aws cloudformation deploy --template-file output.yaml --stack-name demo --capabilities CAPABILITY_IAM
重要なのはdeployのところか
なるほど、testも理解しておかないとあかんな…
devブランチにpushされたら…
masterブランチにpushされたら… など設定できる
– service: 対象のジョブ実行中に起動するDockerイメージ, scriptsを実行するためのDockerイメージ servicesで指定されたコンテナはimagesで指定されたコンテナとは別で起動
– only: 対象ジョブの実行を特定のブランチや特定のタグがプッシュされた時に限定することがd系る
– artifact: ジョブの成果物としてジョブを跨いで共有できる
– when: ジョブを実行するタイミング
L on_success, on_failure, always, on_failure
– environment: 対象のジョブがどの環境へデプロイを行うのか定義できる
なるほど、そろそろ実際にやってみるか
