Ошибка ключа кэша CircleCI, которая молча обслуживает ваши устаревшие зависимости

Трубопровод CircleCI зеленый. Каждая работа проходит. И все же ваше приложение работает против версии зависимости, которая не поставлялась в течение месяца — никто не совершал ее, никто не ударил ее, она просто тихо появилась в производстве. Если вы преследовали баг, как этот, виновник почти никогда не ваш код. Это твой ключ от кэша. Это пятиминутное чтение и пятнадцатиминутное исправление. Быстрая победа в пятницу, развернута к вам. Режим кэширования зависимостей CircleCI работает по простому контракту: вы вычисляете ключ из чего-то, что меняется при изменении ваших зависимостей (обычно контрольная сумма файла блокировки), и вы сохраняете / восстанавливаете кэш, привязанный к этому ключу. Контракт нарушается тремя конкретными, чрезвычайно распространенными способами: Вы проверяете не тот файл. Выглядит разумно, пока кто-то не столкнется с транзитивной зависимостью, не касаясь. Контрольная сумма не двигается. CircleCI с радостью возвращает префикс на прошлой неделе, и люди думают, что он точно соответствует. CircleCI сначала пробует ваш основной ключ, а затем падает в порядке, и первый из них представляет собой префиксный матч против существующих записей кэша, а не «дать мне новейший точный матч». Если ваш список ключей восстановления слишком груб (например, просто ), вы можете восстановить кэш, построенный из совершенно другой ветки, с совершенно другим файлом блокировки, и работа не потерпит неудачу. Он просто тихо ничего не установит (удар кэша, видит, что модули «там») или работает против неправильных версий. Нет никакой версии аварийного люка. Когда вам неизбежно нужно заставить кэш каждого признать недействительным — поврежденный вход в кэш, миграция менеджера пакетов, изменение формата файла блокировки — нет дешевого способа сделать это, потому что ключевой формат никогда не был разработан с учетом ручного взломщика. Каждый из них бесшумно проваливается. Никакого красного X. Никаких ошибок в журналах. Просто стройка, которая работала с устаревшим состоянием, и сообщение об ошибке через три дня о том, что никто не может воспроизвести локально, потому что локально нормально. Замените любой текущий блок кэша этой формой: четыре конкретных изменения, каждое из которых фиксирует один из режимов отказа выше: проверьте файл блокировки, а не манифест. / / / - все, что на самом деле соответствует вашим разрешенным версиям. Это единственный файл, где "ничего не изменилось" - это истинное утверждение о вашем дереве зависимости. (или ) в качестве команды установки, всегда. Это защитная сетка для режимов отказа, которые вы еще не исправили: если кэш-память восстановила что-то устаревшее, замороженная установка отказывается молча продолжать работу с несоответствующим файлом блокировки вместо того, чтобы тихо примирить его. Вы хотите, чтобы эта работа была красной, а не зеленой с неправильным деревом. Заказывайте от большинства к наименее конкретному и остановитесь на одном уровне, чтобы «соответствовать чему-либо». Точный матч на ветке первый, префикс на ветке второй, глобальный префикс последний в качестве подлинного последнего средства для совершенно новой ветви. Не просто иметь в качестве единственного запасного варианта - это линия, которая позволяет ветви восстановить кэш с другим файлом блокировки полностью. Нажмите на ведущий токен версии ( → ) всякий раз, когда вам нужен чистый лист. Это твой ручной кэш-бастер. Поскольку он запекается в самом ключе, принудительное аннулирование для всех является однолинейным PR, а не билетом поддержки в CircleCI или поездкой через пользовательский интерфейс настроек проекта, чтобы вручную обжечь тайники. Проверка действительно сработала Не просто отправить изменения ЯМЛ и доверять ему. Добавьте шаг в неделю, пока вы подтверждаете свое поведение: Настройте название пакета на любую зависимость, которая укусила вас раньше, или на то, что ваша команда больше всего хотела бы знать, отправила неправильную версию. Если этот грэп когда-либо терпит неудачу, ваш кэш и ваш файл блокировки расходятся — и теперь он выходит из строя громко, в CI, а не тихо, в производстве. Ловушка монорепо Если вы находитесь на рабочем месте Yarn / npm или монорепо с несколькими замковыми файлами, функция контрольной суммы только хэширует то, что вы говорите. В корневой строке repo не будет обнаружено изменение собственных зависимостей пакета рабочего пространства, если только ваш менеджер пакетов не напишет это разрешение обратно в файл блокировки корня (большинство из них делают это, но проверяют его для вашего). Если у вас есть вложенные замки, которые не должны быть