最初の設定内容として。
ここのやり方が、さわりとして一番わかりやすい。
公式Docは以下。
プロジェクトのページ/設定/CICD
を選択し、runnerを選ぶ。runnerが存在しない場合は、プロジェクトrunnerから新しく作る。
なお、画像ではプロジェクトがグループに存在していないため、グループrunnerが一つも表示されていないが、このプロジェクトがグループに存在していると、利用できるrunnerが表示される。
gitlab-ci.ymlの確認
「ビルド」→「パイプライン」の中に、helloworldを実行するテストテンプレートがあるので、これを試す事が可能。
これを編集、改造していく事で、gitlab-ciを実行していくことになる。
runnerの指定。
runnerは、ci.yml内のtagsで設定できる。runnerにはタグが設定されており、ci.ymlで指定したタグを持つrunnerから実行させることができる。
以下のような設定で、mgmtとdockerのタグを持つrunnerから実行される。また、同じ条件のタグを持つ複数のrunnerがいる場合は、そこからランダムに実行される。
default:
tags:
- mgmt
- docker
ステージについて。
ステージはいわゆる、ansibleでいうタスクみたいな感じで、実行する内容をまとめた単位。
以下のような内容だと、
- syntax-checkというステージにて、
- ansible-lint
- check-zone
というジョブを走らせるという内容である。stage: ステージ名で記載できる。
stages:
- syntax-check
ansible-lint:
stage: syntax-check
image: python:3.9
variables:
script:
- pip install ansible-lint
- chmod 755 ansible
- 略～
check-zones:
stage: syntax-check
image: ubuntu:latest
script:
- bash 略.sh
よく使わられるパラメータは以下を参考にする。
公式Doc
Quitaでまとめてくれているのはこれ。
少し抜粋する。
| パラメーター名 | 詳細 |
|---|---|
| script | Runnerで実行されるシェルスクリプト。コマンドでも可。 |
| image | 利用するDockerコンテナイメージ。 次の指定も可能: image:name, image:entrypoint. |
| services | サービスで利用するDockerコンテナイメージ。 次の指定も可能: services:name, services:alias, services:entrypoint, services:command. |
| before_script | ジョブを実行する前に動かすコマンドを設定。 |
| after_script | ジョブを実行した後に動かすコマンドを設定。 |
| stages | パイプラインのステージリストを定義。 |
| stage | ジョブのステージ名を定義（デフォルト: test）。 |
| only | ジョブが実行される条件を設定。 次の指定も可能: only:refs, only:kubernetes, only:variables, only:changes. |
| except | ジョブが実行されない条件を設定。 次の指定も可能: except:refs, except:kubernetes, except:variables, except:changes. |
| rules | ジョブの属性を評価して作成するかどうかを決める条件リスト。only/exceptとは同時利用不可。 |
| tags | Runnerに設定されているタグを元に、特定のRunnerで実行。 |
| allow_failure | ジョブの失敗を許容する。失敗してもコミットステータスは変更されない。 |
| when | ジョブを実行するタイミング。 次の指定も可能: when:manual, when:delayed. |
| environment | ジョブをデプロイする環境名。 次の指定も可能: environment:name, environment:url, environment:on_stop, environment:action. |
| cache | ジョブ間で共有するキャッシュのファイルリスト。 次の指定も可能: cache:paths, cache:key, cache:untracked, cache:policy. |
| artifacts | ジョブが成功したときに生成する成果物のファイルやディレクトリ。 次の指定も可能: artifacts:paths, artifacts:name, artifacts:untracked, artifacts:when, artifacts:expire_in, artifacts:reports, artifacts:reports:junit.Enterprise Editionではさらに次が利用可能: artifacts:reports:codequality, sast, dependency_scanning, container_scanning, dast, license_management, performance, metrics. |
| dependencies | 複数のジョブの依存関係を設定し、成果物を受け渡すことが可能。 |
| coverage | ジョブのテストカバレッジ抽出設定。 |
| retry | ジョブ失敗時の自動リトライ回数や条件を設定。 |
| timeout | プロジェクト全体設定より優先される、ジョブ単位のタイムアウトを定義。 |
| parallel | ジョブを並列実行するインスタンス数を設定。 |
| trigger | 連携した下位パイプラインを呼び出す設定。 |
| include | 外部のYAMLファイルを読み込み追加する設定。 次の指定も可能: include:local, include:file, include:template, include:remote. |
| extends | 他のジョブ設定を読み込んで拡張する設定。 |
| pages | GitLab Pagesを使ってジョブの結果をアップロードする設定。 |
| variables | ジョブレベルで変数を設定。 |
| interruptible | 新しいパイプライン実行時にジョブをキャンセル可能にする設定。 |
| resource_group | ジョブの同時実行制限_ |
Ansibleでは、ステージ毎に環境が設定される。そのため、ansibleをセットアップした環境を他のステージに引き継ぐには、少し設定を追加する必要がある。
Gitlab-CIで作成したファイルをDLする。
artifactsというパラメータを用いる事で、そこで指定したファイルをGitlabからDLする事ができるようにする。具体的な指定方法は以下の通り。
# pathsで指定したファイルをDLできるようにする。
artifacts:
paths:
- "*.xlsx" # ここに、DL予定のファイル名を記載。
expire_in: 1 week # ダウンロード可能期間
これを指定した後、ジョブの実行結果の所から以下の画像のようにDLを選択できるボタンが表示される。これを押す事でファイルをDLする事ができる。
