FROM mcr.microsoft.com/dotnet/core/sdk:3.1-buster AS build
WORKDIR /
COPY NuGet.Config /root/.nuget/NuGet/NuGet.Config
WORKDIR /src
COPY ["src/prj/prj.csproj", "src/prj/"]
COPY ["src/test/test.csproj", "src/test/"]
RUN dotnet restore "src/prj/prj.csproj"
COPY . .
WORKDIR "/src/src/prj"
#где-то тут нужно копировать файлы для тестов и запускать эти тесты
RUN dotnet build "prj.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "prj.csproj" -c single_exe -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "prj.dll"]
Необходимо в докере скопировать файлы для тестов, как-то получить результат выполнения тестов (успех или нет).
1) как это сделать -- запуск тестов и получение результатов теста;
2) самое главное, как быть с тестовыми файлами, которые для образа не нежны и весят почти ~200Мб?
Для пункта 2) пока видятся две опции -- на этапе сборки в TC создать отдельный контейнер для тестов,
т.е. просто создать образ, прогнать тесты, если все успешно продолжаем дальше и создаем уже другой,
рабочий образ. Минус видится -- все это долго, да и не нужный образ создается. Второй вариант --
все делать в одном контейнере, по результатам теста давать какой-то отчет,
далее все ненужные файлы удаляются и остаются только библиотеки и/или один исполняемый файл.
Здравствуйте, Sharov, Вы писали: S>Допустим имеется сл. Dockerfile : S>
стандартный набор
S>
S>FROM mcr.microsoft.com/dotnet/core/sdk:3.1-buster AS build
S>WORKDIR /
S>COPY NuGet.Config /root/.nuget/NuGet/NuGet.Config
S>WORKDIR /src
S>COPY ["src/prj/prj.csproj", "src/prj/"]
S>COPY ["src/test/test.csproj", "src/test/"]
S>RUN dotnet restore "src/prj/prj.csproj"
S>COPY . .
S>WORKDIR "/src/src/prj"
S>#где-то тут нужно копировать файлы для тестов и запускать эти тесты
S>RUN dotnet build "prj.csproj" -c Release -o /app/build
S>FROM build AS publish
S>RUN dotnet publish "prj.csproj" -c single_exe -o /app/publish
S>FROM base AS final
S>WORKDIR /app
S>COPY --from=publish /app/publish .
S>ENTRYPOINT ["dotnet", "prj.dll"]
S>
S>Необходимо в докере скопировать файлы для тестов, как-то получить результат выполнения тестов (успех или нет). S>1) как это сделать -- запуск тестов и получение результатов теста; S>2) самое главное, как быть с тестовыми файлами, которые для образа не нежны и весят почти ~200Мб? S>Для пункта 2) пока видятся две опции -- на этапе сборки в TC создать отдельный контейнер для тестов, S>т.е. просто создать образ, прогнать тесты, если все успешно продолжаем дальше и создаем уже другой, S>рабочий образ. Минус видится -- все это долго, да и не нужный образ создается. Второй вариант -- S>все делать в одном контейнере, по результатам теста давать какой-то отчет, S>далее все ненужные файлы удаляются и остаются только библиотеки и/или один исполняемый файл.
ну для такого докер не нужен. если ты конечно не библитеку пишеш для NET Framework и NET Core. и nuget.config как web.config "уточняется" в каждой подпапке.
А тесты с базами редисами и кучей своих прочих сервисов как системы целиком делаются опцией --exit-code-from имя_котнейнера_с_тестами
docker-compose up --exit-code-from tests
тут tests — это контейнер с единственной командой dotnet test
Здравствуйте, VladCore, Вы писали:
VC>ну для такого докер не нужен. если ты конечно не библитеку пишеш для NET Framework и NET Core. и nuget.config как web.config "уточняется" в каждой подпапке.
Просили прогонять в самом докере. А что не так с nuget.config? Там все необходимые репозитории для restore.
Непонятно почему в дотнетный форум.
Варианта два:
1) Строим базовый образ без тестов, потом на его основе другой образ, с тестами.
2) Тесты кладем в отдельный контейнер, на папку с тестами создаем volume, тот же volume подключаем к основному контейнеру
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Варианта два: НС>1) Строим базовый образ без тестов, потом на его основе другой образ, с тестами.
Это надо на каждый билд? Просто что делать если файлов для тестов добавиться? Каждый раз вручную что-то
пересоздавать?
НС>2) Тесты кладем в отдельный контейнер, на папку с тестами создаем volume, тот же volume подключаем к основному контейнеру
Т.е. создаю контейнер, на папку с тестами создаем volume (чтобы это пока для меня ни значило, я только изучаю
технологию), подключаю volume => могу же его и отключить, так? Т.е. если тесты прошли успешно, отключаю volume
и все?
Как вообще из докера можно результаты тестов манифестировать для того же TC, чтобы он дальше что-то делал или
не делал?
Здравствуйте, Sharov, Вы писали:
НС>>Варианта два: НС>>1) Строим базовый образ без тестов, потом на его основе другой образ, с тестами. S>Это надо на каждый билд?
В смысле? А ты образы что, не на каждый билд собираешь?
НС>>2) Тесты кладем в отдельный контейнер, на папку с тестами создаем volume, тот же volume подключаем к основному контейнеру S>Т.е. создаю контейнер, на папку с тестами создаем volume (чтобы это пока для меня ни значило, я только изучаю S>технологию), подключаю volume => могу же его и отключить, так? Т.е. если тесты прошли успешно, отключаю volume S>и все?
Да.
S>Как вообще из докера можно результаты тестов манифестировать для того же TC, чтобы он дальше что-то делал или S>не делал?
Надо примаунтить физическую папку, в нее писать результат, потом в ТС оттуда брать файлы.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Это надо на каждый билд? НС>В смысле? А ты образы что, не на каждый билд собираешь?
На каждый, но может тут надо какой-то эталонный собрать и держать про запас.
S>>Как вообще из докера можно результаты тестов манифестировать для того же TC, чтобы он дальше что-то делал или S>>не делал? НС>Надо примаунтить физическую папку, в нее писать результат, потом в ТС оттуда брать файлы.
Здравствуйте, Sharov, Вы писали:
S>Необходимо в докере скопировать файлы для тестов, как-то получить результат выполнения тестов (успех или нет). S>1) как это сделать -- запуск тестов и получение результатов теста;
Все как обычно. Копируешь файлы тестов в контейнер (COPY), запускаешь эти тесты (RUN).
Если тесты успешно пройдены (retcode = 0), то сборка продолжится.
Если тесты упали (retcode != 0), то сборка остановится с ошибкой
S>2) самое главное, как быть с тестовыми файлами, которые для образа не нежны и весят почти ~200Мб?
У тебя же multi-stage сборка. В последний контейнер (final) тестовые файлы не попадут.
Здравствуйте, Буравчик, Вы писали:
НС>>Запускать тесты в процессе сборки имаджа? Злобненько. Б>Я согласен, идея странная. Но мне показалось, что именно этого хочется. Б>Всякое бывает нужно...
Тоже казалось, что идея прогона тестов во время сборки образа странновата.
С другой стороны нужно проверить, что все работает в самом докере.
Т.е. некая часть общая -- образ с исполняемым файлом, а некоторая опциональная --
volume(или что-то вроде) с тестами. С другой стороны, зачем мне исполняемый файл для тестов?
Мне нужны файлы проекта и тестовый проект + бинарные файлы для тестов.
Может как-то так сделать?
COPY ["src/prj/prj.csproj", "src/prj/"]
COPY ["src/test/test.csproj", "src/test/"]
RUN dotnet restore "src/prj/prj.csproj"
COPY . .
WORKDIR "/src/src/prj"
#где-то тут нужно копировать файлы для тестов и запускать эти тесты
RUN dotnet build "prj.csproj" -c Release -o /app/build
ENTRYPOINT ["dotnet", "test","test.prj"]
А потом из TC "docker run img" и анализировать код возврата?
PS: Подумал, что много restore и build получается, отдельные шаги при сборке, при создании образа для тестов,
при создании образа для релиза. С одной сторны, раньше узнаю о проблеме, с др. что будет, если проблема обнаружится
в образа докера, как он себя поведет?
Здравствуйте, Sharov, Вы писали:
S>А потом из TC "docker run img" и анализировать код возврата?
И приложение ты будешь из этого докера запускать? Ты же хотел убрать тестовые код/файлы.
Обычно, приложение и тесты складывают в один докер, это самое простое и удобное.
В cmd по-умолчанию прописывают запуск приложения, чтобы просто запускать контейнер docker run.
А для вызова тестов просто подменяешь cmd при запуске — docker run mycommand
Частенько также используют entrypoint-скрипт, который по ключевому определяет что надо запустить — приложение, тесты и др
Минусы этого подхода — в образе хранится ненужный код (например, тесты).
Удалить что-нибудь из образа невозможно. Поэтому если ты хочешь уменьшить размер образа, не включая туда тестовый код, то тебе придется делать два образа — один для релиза, другой для тестов. Здесь есть варианты:
— это могут быть абсолютно разные образы, создаваемые с нуля (dockerfile будут частично дублироваться)
— образ для релиза создается с нуля, а тестовый использует его как базу и добавляет дополнительные тестовые файлы
— оба образа создаются из некоторого заранее подготовленного базового, который содержит общие файлы
Здравствуйте, Буравчик, Вы писали:
Б>Здравствуйте, Sharov, Вы писали:
S>>А потом из TC "docker run img" и анализировать код возврата?
Б>И приложение ты будешь из этого докера запускать? Ты же хотел убрать тестовые код/файлы.
Б>Обычно, приложение и тесты складывают в один докер, это самое простое и удобное. Б>В cmd по-умолчанию прописывают запуск приложения, чтобы просто запускать контейнер docker run. Б>А для вызова тестов просто подменяешь cmd при запуске — docker run mycommand Б>Частенько также используют entrypoint-скрипт, который по ключевому определяет что надо запустить — приложение, тесты и др
Б>Минусы этого подхода — в образе хранится ненужный код (например, тесты).
Б>Удалить что-нибудь из образа невозможно. Поэтому если ты хочешь уменьшить размер образа, не включая туда тестовый код, то тебе придется делать два образа — один для релиза, другой для тестов. Здесь есть варианты: Б>- это могут быть абсолютно разные образы, создаваемые с нуля (dockerfile будут частично дублироваться) Б>- образ для релиза создается с нуля, а тестовый использует его как базу и добавляет дополнительные тестовые файлы Б>- оба образа создаются из некоторого заранее подготовленного базового, который содержит общие файлы
Тут, как я понял, идея в следующем -- один докер файл из которого делаются (--target) разные образы. Т.е.
образ для тестов, образ для прод и т.д. А сам докер файл один. И главное, вроде бы никакого роста объема контейнера.
Здравствуйте, Sharov, Вы писали:
S>Тут, как я понял, идея в следующем -- один докер файл из которого делаются (--target) разные образы. Т.е. S>образ для тестов, образ для прод и т.д. А сам докер файл один. И главное, вроде бы никакого роста объема контейнера.
