言語ガイド: Clojure

このガイドでは、CircleCI 2.0 で Clojure アプリケーションをビルドする方法について説明します。お急ぎの場合は、後述の設定ファイルの例をプロジェクトのルートディレクトリにある .circleci/config.yml に貼り付け、ビルドを開始してください。

設定ファイルの例
コードの取得
設定ファイルの詳細

概要

お急ぎでなければ、設定ファイルの詳細に目を通すことをお勧めします。

ここでは、以下を前提としています。

Leiningen の組み込み test タスクを含む clojure.test を使用している
アプリケーションをオールインワン uberjar として配布できる

他のテストツールを使用する場合は、別の lein タスクを実行するようにそのステップを調整するだけです。

設定ファイルの例

version: 2 # CircleCI 2.0 を使用します
jobs: # 1 回の実行の基本作業単位
  build: # ワークフローを使用しない実行では、エントリポイントとして `build` ジョブが必要です
    working_directory: ~/cci-demo-clojure # ステップが実行されるディレクトリ
    docker: # Docker でステップを実行します
      - image: circleci/clojure:lein-2.9.1 # ...このイメージをすべての `steps` が実行されるプライマリ コンテナとして使用します
    environment: # プライマリ コンテナの環境変数
      LEIN_ROOT: nbd
      JVM_OPTS: -Xmx3200m # メモリ不足エラーを回避するために最大ヒープ サイズを制限します
    steps: # `build` ジョブを構成するコマンド
      - checkout # ソース コードを作業ディレクトリにチェックアウトします
      - restore_cache: # 最後の実行からチェックサムが変化していない場合は、保存されているキャッシュを復元します
          key: cci-demo-clojure-{{ checksum "project.clj" }}
      - run: lein deps
      - save_cache: # キー テンプレートを使用してキャッシュを生成し .m2 ディレクトリに保存します
          paths:
            - ~/.m2
          key: cci-demo-clojure-{{ checksum "project.clj" }}
      - run: lein do test, uberjar
      - store_artifacts: # アーティファクト (https://circleci.com/ja/docs/2.0/artifacts/) に表示するテスト サマリーをアップロードします
          path: target/uberjar/cci-demo-clojure.jar
          destination: uberjar
      # デプロイ例については https://circleci.com/ja/docs/2.0/deployment-integrations/ を参照してください     

コードの取得

上記は Clojure デモアプリケーションの設定ファイルの抜粋です。このデモアプリケーションには、https://github.com/CircleCI-Public/circleci-demo-clojure-luminus からアクセスできます。

ご自身でコード全体を確認する場合は、GitHub でプロジェクトをフォークし、ローカルマシンにダウンロードします。 CircleCI で [Add Projects (プロジェクトの追加)] ページにアクセスし、プロジェクトの横にある [Build Project (プロジェクトのビルド)] ボタンをクリックします。最後に .circleci/config.yml の内容をすべて削除します。

これで config.yml を最初からビルドする準備ができました。

設定ファイルの詳細

常にバージョンの指定から始めます。

version: 2

次に、jobs キーを記述します。 1 つひとつのジョブが、ビルド、テスト、デプロイのプロセス内の各段階を表します。このサンプルアプリケーションでは 1 つの build ジョブのみが必要なので、他の要素はそのキーの下に置きます。

各ジョブには、working_directory を指定するオプションがあります。この例では、ホームディレクトリにあるプロジェクトから名前を付けます。

version: 2
jobs:
  build:
    working_directory: ~/cci-demo-clojure

他のディレクトリを指定しない限り、以降の job ではこのパスがデフォルトの作業ディレクトリとなります。

working_directory の直下の docker キーで、コンテナイメージを指定できます。

version: 2
...
    docker:
      - image: circleci/clojure:lein-2.9.1

lein-2.7.1 タグを指定して CircleCI 提供の Clojure イメージを使用します。

ここでは、メモリ不足エラーが発生しないように、JVM_OPTS を設定して最大ヒープサイズを制限します。標準のコンテナの制限は 4 GB ですが、JVM がヒープ外に確保する分と Leiningen 自体のために、いくらかの容量を残しておきます (場合によっては、lein trampoline ... を使用して Leiningen のオーバーヘッドを回避できます)。たとえば、データベースまたはキューのためのバックグラウンドコンテナがある場合は、メインの JVM ヒープにメモリを割り当てる際にそれらのコンテナを考慮してください。

通常、Leiningen は非 root ユーザーとして実行されることを前提とし、root として実行しているユーザーは例外的と見なします。この例では、それが意図的であることを示すために LEIN_ROOT 環境変数を設定します。

    environment:
      JVM_OPTS: -Xmx3200m
      LEIN_ROOT: nbd

この build ジョブ内にいくつかの steps を追加します。

コードベースで作業できるように、最初に checkout を置きます。

次に、キャッシュをプルダウンします (存在する場合)。初回実行時、または project.clj を変更した場合、これは実行されません。さらに lein deps を実行して、プロジェクトの依存関係をプルダウンします。通常、このタスクは必要時に自動的に実行されるため、これを直接呼び出すことはありません。ただし、このタスクを直接呼び出すことで、save_cache ステップを挿入して依存関係を保存し、次回の処理を高速化することができます。

その後、lein do test, uberjar によって実際のテストが実行されます。テストが正常に終了した場合は、アプリケーションソースとすべての依存関係を含む “uberjar” ファイルが作成されます。

最後に store_artifacts ステップを使用して、uberjar をアーティファクトとして保存します。そこから、これを目的の継続的デプロイスキームに結び付けることができます。

...
    steps:

      - checkout
      - restore_cache:
          key: cci-demo-clojure-{{ checksum "project.clj" }}
      - run: lein deps
      - save_cache:
          paths:
            - ~/.m2
          key: cci-demo-clojure-{{ checksum "project.clj" }}
      - run: lein do test, uberjar
      - store_artifacts:
          path: target/cci-demo-clojure.jar
          destination: uberjar

完了です。これで Clojure アプリケーション用に CircleCI をセットアップできました。

言語ガイド: Clojure

概要

設定ファイルの例

コードの取得

設定ファイルの詳細

関連項目

詳細な例