Налаштування CircleCI 2.0 для Rails

У липні 2017 CircleCI випустила версію 2.0 своєї платформи. Вона стала набагато потужнішою й більш гнучкою. Але разом з цим, її стало складніше розгорнути та налаштувати на роботу з Rails застосунками.

Базова конфігурація

Файл конфігурації CircleCI тепер знаходиться в .circleci/config.yml. Він повинен виглядати ось так:

---
version: 2
jobs:
    build:
        working_directory: ~/your-app-name
    steps:
        - checkout

Тут не відбувається нічого особливого (і нічого не працює саме по собі). Це основна оболонка файлу конфігурації.

Вибір основного образу Docker

Для нашого варіанту використання, найкращим вибором буде Docker executor, який створить середовище з набору образів Docker. CircleCI надає набір попередньо створених образів, які ми будемо використовувати. Вони охоплюють багато різних версій Ruby, з варіаціями загальних вимог, таких як браузер та/або JavaScript.

Ці варіації можуть бути вказані за допомогою тегів у образі Docker, як наприклад:

---
version: 2
jobs:
    build:
        working_directory: ~/your-app-name
        docker:
            - image: circleci/ruby:2.4.1
            environment:
                RAILS_ENV: test
    steps:
        - checkout

      # Встановлення середовища
      - run: cp .sample.env .env

      # Запуск тестів
      - run: bundle exec rake

Це додасть образ Ruby 2.4.1. Якщо нам потрібен браузер, ми можемо використати тег 2.4.1-browsers (наприклад, для Selenium). Якщо у нас є JavaScript тести, ми використаємо 2.4.1-node, а якщо у нас є обидва варіанти, то 2.4.1-node-browsers.

Тепер у нас є середовище для роботи, в яке ми додамо все, що нам потрібно для запуску тестів. Ваше середовище може відрізнятися.

Сервіси

Застосунок Rails рідко буває без БД й ми можемо додати її за допомогою іншого образу Docker. Ми використовуватимемо PostgreSQL, але все інше працюватиме так само:

---
version: 2
jobs:
  build:
    working_directory: ~/your-app-name
    docker:
      - image: circleci/ruby:2.4.1
        environment:
          PGHOST: localhost
          PGUSER: your-app-name
          RAILS_ENV: test
      - image: postgres:9.5
        environment:
          POSTGRES_USER: your-app-name
          POSTGRES_DB: your-app-name_test
          POSTGRES_PASSWORD: ""
    steps:
        - checkout

      # Встановлення середовища
      - run: cp .sample.env .env

      # Встановлення бази даних
      - run: bundle exec rake db:setup

      # Запуск тестів
      - run: bundle exec rake

Так ми додамо образ postgres та деяку конфігурацію середовища. Ми надаємо значення аналогічні до тих, які ми використовуємо в config/database.yml. Зазначивши POSTGRES_DB в образі postgres, ми забезпечимо створення коректної БД.

Крім того, тут ми додаємо команди rake для конфігурування бази даних.

Наш файл конфігурації тепер повинен успішно виконувати тести. Але це ще не все. Потрібно ітерувати по основному образу Docker, щоб впевнитись, що покриваються всі залежності й більшість прогонів проходять успішно.

Уникання станів гонитви (race conditions)

Проблема, про яку ми повинні потурбуватися, — стан гонитви, пов'язаний з тим, як запускаються додаткові сервіси. Postgres може потребувати більше часу, щоб стати доступним, тож наші тести можуть запуститися... і завершитися невдачею.

Щоб вирішити цю проблему, ми можемо використати dockerize, для очікування доступності порту. Додайте це як крок запуску:

- run: dockerize -wait tcp://localhost:5432 -timeout 1m

Кешування залежностей

Запуск bundle для кожного тестового прогону може бути повільним, але простим для кешування. Щоб трохи збільшити швидкість, ми можемо використати щось на зразок цього:

# Відновлення кешованих залежностей
- type: cache-restore
  name: Restore bundle cache
  key: your-app-name-{{ checksum "Gemfile.lock" }}

# Залежності встановлення пакету
- run: bundle install --path vendor/bundle

# Кешування залежностей
- type: cache-save
  name: Store bundle cache
  key: your-app-name-{{ checksum "Gemfile.lock" }}
  paths:
    - vendor/bundle

Так ми спробуємо відновити будь-які кешовані залежності, використовуючи контрольну суму на основі файлу блокування. Встановлення залежностей з певним шляхом дозволяє нам використовувати cache-save, щоб зберегти цю конкретну теку.

Об'єднання цього всього разом

Що ми отримуємо, зібравши все це докупи:

---
version: 2
jobs:
  build:
    working_directory: ~/your-app-name
    docker:
      - image: circleci/ruby:2.4.1
        environment:
          PGHOST: localhost
          PGUSER: your-app-name
          RAILS_ENV: test
      - image: postgres:9.5
        environment:
          POSTGRES_USER: your-app-name
          POSTGRES_DB: your-app-name_test
          POSTGRES_PASSWORD: ""
    steps:
      - checkout

      # Відновлення кешованих залежностей
      - type: cache-restore
        name: Restore bundle cache
        key: your-app-name-{{ checksum "Gemfile.lock" }}

      # Залежності встановлення пакету
      - run: bundle install --path vendor/bundle

      # Кешування залежностей
      - type: cache-save
        name: Store bundle cache
        key: your-app-name-{{ checksum "Gemfile.lock" }}
        paths:
          - vendor/bundle

      # Очікування бази даних
      - run: dockerize -wait tcp://localhost:5432 -timeout 1m

      # Встановлення середовища
      - run: cp .sample.env .env

      # Встановлення бази даних
      - run: bundle exec rake db:setup

      # Запуск тестів
      - run: bundle exec rake

Ви можете побачити цю конфігурацію у дії на administrate