Как указать разные файлы .dockerignore для разных сборок в одном проекте?

Я использовал список tests в .dockerignore, чтобы он не включался в изображение, которое я использовал для запуска веб-службы.

Теперь я пытаюсь использовать Docker для запуска моих модульных тестов, и в этом случае я хочу включить каталог tests.

Я проверил docker build -h и не нашел никакой опции.

Как я могу это сделать?

Ответы

Ответ 1

Докер 19.03 поставил решение для этого.

Клиент Docker сначала пытается загрузить <dockerfile-name>.dockerignore, а затем возвращается к .dockerignore, если его не удается найти. Поэтому docker build -f Dockerfile.foo . сначала пытается загрузить Dockerfile.foo.dockerignore.

Установка переменной среды DOCKER_BUILDKIT=1 в настоящее время требуется для использования этой функции.

Смотрите также:

Ответ 2

На данный момент нет никакого способа сделать это. Существует длинная дискуссия о добавлении флага --ignore к Docker для обеспечения использования файла игнорирования - см. здесь.

Параметры, которые у вас есть на данный момент, в основном уродливы:

  • Разделите проект на подкаталоги, каждый из которых имеет свои собственные Dockerfile и .dockerignore, которые могут не работать в вашем случае.
  • Создайте script, который копирует соответствующие файлы во временный каталог и запускает там сборку Docker.

Ответ 3

Добавление очищенных тестов в качестве монтирования тома в контейнер может быть здесь. После того, как вы построите изображение, запустите его для тестирования, смонтируйте исходный код, содержащий тесты поверх очищенного кода.

services:
   tests:
      image: my-clean-image
      volumes:
         - '../app:/opt/app' # Add removed tests

Ответ 4

Другим вариантом является следующий процесс сборки, включающий тесты. Как я это делаю:

Если тесты являются модульными тестами, я создаю новое изображение Docker, которое получается из основного изображения проекта; Я просто вставляю FROM вверху, а затем ADD тесты, а также любые необходимые инструменты (в моем случае mocha, chai и т.д.). Это новое "тестовое" изображение теперь содержит как тесты, так и исходный источник для тестирования. Затем он может быть просто запущен как есть или может быть запущен в режиме просмотра с томами, сопоставленными с вашими источниками и тестовыми каталогами на хосте.

Если тесты являются интеграционными тестами - например, основным изображением может быть сервер GraphQL, то созданное мной изображение является самодостаточным, т.е. не является производным от основного изображения (оно все еще содержит тесты и инструменты, конечно). В моих тестах используются переменные среды, чтобы сообщить им, где найти конечную точку, которая нуждается в тестировании, и достаточно легко получить Docker Compose для вызова как контейнера с использованием основного изображения, так и другого контейнера, использующего образ тестирования интеграции, и установить переменные среды так что тестовый пакет знает, что тестировать.