gitlab-ci事始め

Oct 7, 2020 git gitlab gitlab-ci

GitLab CIを使ってみます。ここではCIっていうものに関して名前はちょっと聞いた事あるけど何なんだかよくわからんなとか、聞いた事すらない人でも対応できるくらいの難易度に抑えようとしてはいますが、以下の前準備とか知識は必要です。

gitlabのアカウント。
gitがインストールされている事。gitの最低限commitとかpushとかはできる事。
ちょっと程度のlinux(unix)の知識。

プログラミングの知識は全く問いません。

gitlabプロジェクトの作成

CIが何というのはとりあえず置いておきます。Gitlab CIはプロジェクトごとに仕掛けるものだったりするので、何にせよプロジェクトを作成する必要があります。

gitlabアカウントあるならプロジェクトくらいは作った事あると思うので、適当に練習用のを作ってください。名前は何でもいいです。ci-testとか適当に。中身はブランクでokだし、privateレポジトリでok。とにかく空のやつを作ります。README.mdを置いてしまったとしてもそれはokです。

作ったら、手元にレポジトリをcloneしときます。

CIの考え方

ここでCIってのを少し考えます。これは複数人でプログラムとかする時に有用なのですが、まあ今回はプログラムしないって事で、複数人で例えばテキストファイルを書くのとかを考えてみます。

ちなみにですが、複数人じゃなくても有用です。

今回は1つのテキストドキュメントを仕上げていく事にします。このドキュメントには署名として

1株式会社 ギット

っていう署名が入っていないといけないとします。

他はどんどん文面が変わったり追加修正されていきますが、少なくとも↑の署名は入ってないといけないものとします。

ここで、既にいろいろ疑問が出たり出なかったりすると思いますが、CIは製品の完璧な作りを保証するものでは基本的にないという事になります。この場合、「署名が入っていればいい」というただ一点だけの条件でやるので、たとえば署名が(あんまありえないが)文章の先頭に入っててもOKとみなしますし、その他の誤字は検出しません。逆にいえば、この

1株式会社 ギット

が入ってなければその文章は確実に製品としてアウトという事になりますよね。

誰かが触っててこの署名を消してしまったとか、株式会社の後ろを全角空白にしちゃったとか、または文字コードがおかしいとかまでは検出できると思いますが、とにかくCIを仕掛ける事でこの署名が入っている事は確実に保証されるわけです。これがCIの利点となります。

もちろん、検証を複雑にすれば(今回の場合は署名は必ず文末に入っており、改行のなき事、とか)より高品位の製品クオリティが担保されますが、今度はCIのメンテナンスもしっかり行わないといけないので、ここはトレードオフでしょう。作業者がある程度判別できるような事は任せてしまうというのも1つの方針になりえるでしょう。

はっきりいって今回はプログラミングで使ってないのでちょっとピンとこない所もあるかもですが、とりあえず前段階の能書きはこれくらいにして手を動かしてみましょう。

とりあえず今回はannounce.mdという名前のmarkdown形式のファイルを作成してみる事にしましょう。

announce.md

1# ご案内
2
3本文本文本文
4
5---
6株式会社ギット

としましょう。ご覧の通り間違いを敢えていれてあります。

pushする前にCIを仕掛ける

CIはレポジトリにpushされた時点で起動しますんで、ここからはgitlabでの作業になります。

プロジェクトのトップにこんなボタンがありました。押してみると…

このように本当に何もないテキストエリアに誘導されます。これではちょっと面喰ってしまうんで、テンプレートからbashを呼び出してみましょう。

かなり盛り沢山で奥が深いです。あとシェルなのでやれる事が沢山あるという事で沢山書かれていますけど、、、

とりあえずバッサリ切ります。

1# you can delete this line if you're not using Docker
2image: busybox:latest
3
4test1:
5  stage: test
6  script:
7    -  grep "株式会社 ギット" announce.md

もちろん、最初からこのyamlを貼ってもいいけど、とりあえず何もない所から書くにはどうしたらいいかというチュートリアルなので、なるべく手を動かしてみましょう。

今回は非常にシンプル極まりない形のCIになっています。この構文に関しては後ほど解説しますが、少なくともannounce.mdに対してgrepを行っているのがわかります。本当にただこれだけです。

これで保存(Commit changes)します。

pullする

「Commit changes」とかの名前でわかるように、これはgitlab.comサーバ上に直接commitされ、なんならpushされます。で、gitlabはこの名前のファイルがあるとCIします、そして失敗します。なぜならannounce.mdを置いてないのでgrepは常に失敗するという事になります。

ここでgitlabサーバ上で作成したyamlをpullして手元(ローカル)に持ってきます。

以下はcloneした所での作業となります。

1$ git pull
2...
3 * [new branch]      master     -> origin/master

このようになり、手元に .gitlab-ci.yml がふってきたと思います。そしたら、作成した announce.md をcommitし、pushします。

この段階で早々とすっとばして既にcommitしたりpullする前にpushしちゃったりとかあるかもしれないけど、とにかく手元でマージして2つのファイルを揃えてください。

1% ls -a 
2./  ../  .git/  .gitlab-ci.yml  announce.md
3% git add announce.md
4% git commit -m "first commit"
5% git push

すると、失敗します。まあそりゃそうですね。

失敗するとこういう表示になるし、メールも飛んだりします。slackにぶん投げる事もできます(失敗するとかなりうるさいですが)。

この X を消しにいかないと製品としていつまでもダメクオリティだぞという事になるわけです。

修正する

ここで敢えて間違えておりました「株式会社ギット」を「株式会社ギット」に変更します。

 1diff --git a/announce.md b/announce.md
 2index edaaf05..e526152 100644
 3--- a/announce.md
 4+++ b/announce.md
 5@@ -3,4 +3,4 @@
 6 本文本文本文
 7
 8 ---
 9-株式会社ギット
10+株式会社 ギット

これでcommit → pushします

これで修正できました

まあ、ここまでは予想通りの挙動って事でokですね。これが大体のCIのやる事のオーバービューです。

yamlの内容

ここで改めてyamlの内容を見てみます。

1# you can delete this line if you're not using Docker
2image: busybox:latest
3
4test1:
5  stage: test
6  script:
7    -  grep "株式会社 ギット" announce.md

imageは利用するdockerイメージで、ちょっと割愛します。簡単なシェルを回すだけならbusyboxっていうのが軽量ですが、たとえばrubyとかpythonとかphpとかを検証する場合はこれを変更しないといけません。dockerの知識があればもう少し深い事が解説抜きで出来るでしょう。

test1となっているのはこれは実は好きな名前を与える事ができます(ただし、予約語を除く)なので、好きにしていいわけです。わかりやすい名前なら例えばcheck_signatureとかでもいいという事になります。

続いてその下の階層のstageですが、これは

build
test
deploy

の3フェーズに分けて管理しており、上から下に流れていきます。たとえばCのようなビルドを必要とするプログラムだとまずビルドできないと次に行けないのでビルドを通すという事になります。

ここではプログラムの話をあまりしないという事で記事を書いているわけですが、CIの利点として真っサラな環境でビルドできるので、手元の開発環境で通ってる奴を別環境に持っていったらビルド失敗したンゴとかいう事が起き辛いというのがデカいです。

デフォルトはtestです。なので、実は

1stage: test

は省略可能です。

scriptは必須項目です。テストの環境の中でこれが実行されます。実際の所ほぼlinux/unix環境なので、冒頭で述べたちょっとした知識というのが問われるという事です。まあ実行するコマンドが決まっているならそれほどでもないんですが。

以上を踏まえると、yamlはこうやって書いてもいいという事になりますね。

1# you can delete this line if you're not using Docker
2image: busybox:latest
3
4check_signature:
5  script:
6    -  grep "株式会社 ギット" announce.md

最後、3.のdeployというのは生成されたファイルを別サーバに送りこんだりする時に使うもので、生成されたファイルをどこかに持っていったりという事が必要ならここに書きます。生成しなくてもいいですが…

今回はここまで

正直ここまでの事例で、ナイスな使い方が膨らまなかった人もいるかもしれませんが、ファイルが沢山増えてきたらgrepの範囲を広げるようにすればよかったりだったりとか、あとはもう工夫次第なので、あとは道具の使い方次第という所もあります。

で、やはりこれは何だかんだプログラムに向いているので、今回みたいな案件で仕掛ける事はそうそう無いと思いますが、たとえばphpというかlaravelのテストを毎回かけたいとか、そういう場合には非常に向いています。そしてtestに失敗してcommitするたびにイライラするという未来があるわけですね。

ただ、今イライラするか、後でイライラするかの違いで、苦労は先にしておけって話がCIの役割って事になるんだろうと思います。

以上です。なんかlaravelの話とかしたから今度はそういう系での事例を書いてみましょう。