CircleCI

【CircleCI】working_directoryの挙動を実験して確かめてみた話

【CircleCI】working_directoryの挙動を実験して確かめてみた話

CircleCIの設定ファイルである.circleci/config.ymlについて勉強し始めたとき、以下のことが気になりました。

working_directoryって何をしてるんだ??

 

何となく、「作業場所」ということは分かりますが、コンテナに展開するためのローカルのディレクトリを指定するのか、それともコンテナ内に置きたいディレクトリを指定するのかが分かりません。

公式ドキュメントにも一応説明はあり、「stepsを実行する際のディレクトリを指定」と書かれてありますが、こちらもいまいちハッキリしません。

 

そこで今回は、実際にCircleCIを動かしてみて、working_directoryが何を指しているのかを確かめるべく実験をしてみました。

 

今回はその実験結果をシェアします。少しでも同じ疑問を感じている方の参考になれば幸いです。

CircleCIを使うための準備

まずはCircleCIを使うための準備を行います。

 

あくまで実験のための環境なので、複雑なアプリケーションを用意する必要はありません。

今回はGitHub上にシンプルなプロジェクト(circleci_test)を作成し、コードに変更が加わる毎にCircleCIが動くよう設定しました。

 

次に、ディレクトリ内に適当なファイルREADME.md、circle.htmlおよび.circleci/config.ymlを配置します。(隠しファイルのため、.circleciは表示されていません)

ディレクトリ構成1

 

そしてconfig.yml内に、CircleCI上にコンテナを生成するためのimageやコンテナ内で行う動作を記述していきます。

要は、CircleCIが実行する動作手順を全て記述するイメージです。

 

今回はこんな感じのコードをconfig.ymlに書いてみました。このコードをベース(初期状態)にして実験をしていきます。

version: 2.0
jobs:
 build:
   docker:
     - image: alpine:3.7
   working_directory: ~/experiment
   steps:
     - checkout
     - run:
         name: 実験
         command: |
           pwd 
           ls

 

working_directoryの検証に入る前に、簡単にコードの意味を説明しておきます。

versionCircleCIのバージョンです。1か2か2.1を指定可能ですが、今回は2を指定しています。

 

jobs内ではCI環境上で実行するjobを定義します。

 

本来、jobには任意の名前を付けることができます。

ただ、今回のようにjobが一つだけの場合は、job名を「build」にしなくてはなりませんそのため、今回はjob名として「build」を指定しています。

 

docker:では、jobの実行に必要なDockerイメージを指定しています。この部分ではdocker以外にも、machineもしくはmacosを指定することができます。ただ、CircleCIではDockerの利用が推奨されているとのことです。

今回はイメージとしてalpine:3.7を指定しました。

 

working_directoryについては、後ほど検証するので割愛します。

 

steps:ではCI上で動作させるコマンドやキャッシュ操作などを指定することができます。

checkoutでは、リポジトリのソースコードを展開することができます。挙動は後ほど実験で確認します。

 

run:ではコマンドの実行を宣言しています。

その下のnameは任意のrunの名前で、commandでは実際にCI上で実行する(Linux)コマンドを宣言しています。

※複数コマンドを指定する場合は、上記のようにcommand: |を記述して、その下にコマンドを列挙します。

 

以上でworking_directoryの実験のための準備およびconfig.ymlの中身の説明は完了です。

working_directoryが何を指しているのか、実験してみる

まずは、先ほどのファイルでそのままCircleCIを動かしてみましょう。

GitHub上でこのファイルをコミットするとCircleCIが動き出します。

version: 2.0
jobs:
 build:
   docker:
     - image: alpine:3.7
   working_directory: ~/experiment
   steps:
     - checkout
     - run:
         name: 実験
         command: |
           pwd 
           ls

 

この場合のcommandの実行結果はこちらです。

実験1

この結果から分かることは、今回作成したプロジェクト配下のファイルがworking_directoryで指定したディレクトリの配下に展開されているということです。

 

次に、working_directoryに指定するディレクトリ名を、今回のプロジェクトディレクトリの名前(circleci_test)と同じにしてみました。

version: 2.0
jobs:
 build:
   docker:
     - image: alpine:3.7
   working_directory: ~/circleci_test
   steps:
     - checkout
     - run:
         name: 実験
         command: |
           pwd
           ls

 

この場合はどうなるでしょうか?

 

実行結果はこちらです。

実験2

working_directoryで指定したプロジェクトディレクトリの配下にプロジェクトのファイルが展開されています。

working_directoryの名前がプロジェクトの名前と同一かどうかは、実行結果には関係ないようです。

 

次に、working_directoryの名前を元に戻し、stepsにあるcheckoutをコメントアウトしてみます。

version: 2.0
jobs:
 build:
   docker:
     - image: alpine:3.7
   working_directory: ~/experiment
   steps:
    #  - checkout
     - run:
         name: 実験
         command: |
           pwd
           ls

 

このときの結果が以下です。

実験3

 

experimentディレクトリは作成されていますが、circleci_testプロジェクトディレクトリ配下のファイルは展開されていません

 

 

以上の3つの実験により、以下の事実がハッキリと明確になりました。

working_directoryで指定したディレクトリ配下にプロジェクト内の全ファイルが展開される。ただし、checkoutを指定しない場合は展開されない

 

 

もう少し実験を進めます。

次に、circleci_testディレクトリ配下にtestディレクトリを作成し、その中にtext.txtファイルを生成しました。

次からはこのディレクトリ構造で実験をします。

ディレクトリ構成2

 

まずは以下のようにconfig.ymlを記述し実行してみました。

version: 2.0
jobs:
 build:
   docker:
     - image: alpine:3.7
   working_directory: ~/experiment
   steps:
     - checkout
     - run:
         name: 実験
         command: |
           pwd
           ls

 

 

結果はこちらです。先程と同様、working_directoryに指定したディレクトリ配下にファイル(ディレクトリ)が展開されています。

実験4

 

次に、run内で二つ目のworking_directoryを設置し、そこに適当なディレクトリを指定してみました。この場合はどうなるでしょうか?

version: 2.0
jobs:
 build:
   docker:
     - image: alpine:3.7
   working_directory: ~/experiment
   steps:
     - checkout
     - run:
         working_directory: blogTest
         name: 実験
         command: |
           pwd
           ls

 

この場合の結果は以下のようになりました。

実験5

 

experimentディレクトリ配下にblogTestディレクトリは作成されていますが、その中には何もありません。

 

次に、working_directoryに指定する値を、先ほど追加したtestディレクトリに変えてみました。この場合はどうなるでしょうか。

version: 2.0
jobs:
 build:
   docker:
     - image: alpine:3.7
   working_directory: ~/experiment
   steps:
     - checkout
     - run:
         working_directory: test
         name: 実験
         command: |
           pwd
           ls

 

結果は以下のようになりました。

実験6

 

pwdでtestディレクトリが表示され、その中に先ほど作っておいたtest.txtが表示されています

 

以上の結果から次のことが分かりました。

checkoutによりプロジェクトのファイルが一回目のworking_directoryで指定したディレクトリ配下に展開された後は、再度working_directoryを指定するとプロジェクト内のディレクトリに移動できる(cdコマンドと同じ挙動を示す)。ただし、ディレクトリが存在しない場合は、新たにディレクトリが作成されそこに移動する

 

【CircleCI】working_directoryの結論

今回の実験結果をまとめておきます。

  • checkoutにより、working_directoryに指定したディレクトリ配下にプロジェクト(今回はcircleci_test)のファイルやディレクトリが展開される
  • checkoutによりプロジェクトのファイルが一回目のworking_directoryで指定したディレクトリ配下に展開された後は、再度working_directoryを指定するとプロジェクト内のディレクトリに移動できる(cdコマンドと同じ挙動を示す)

 

要は、プロジェクトのソースコードを展開する際の起点ディレクトリを指定するのに使えるだけでなく、cdコマンドの代わりとしても使うことができるということですね。

 

今回は以上となります。少しでもあなたの疑問解決の一助となっていれば幸いです。

 

参考記事:CircleCI を設定する

COMMENT

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA