Системы сборки *

Приглашаем на вебинар, на котором поговорим, как защитить сборки, избежать зависимостей от внешних репозиториев и повысить надёжность.

На вебинаре вы узнаете:

• требования ДИБов и регулятора

• об атаках на цепочки поставок ПО

• возможности отключения Maven Cenral

• про инженерные проблемы при сборке, с которыми столкнулись, а также пути их решения на примере Axiom JDK

• опыт использования доверенного репозитория в контуре ЕДИНОГО ЦУПИС

• как встроить еще один репозиторий в стандартный Java‑проект. Покажем демонстрацию в режиме реального времени

Кому будет полезен вебинар:
• Архитекторам
• Инженерам
• Всем, кто интересуется РБПО

Вебинар проведут:
• Максим Максимов, Архитектор решений, ЕДИНЫЙ ЦУПИС
• Сергей Лунегов, Директор по продуктам, Axiom JDK

Когда: 12 ноября 2025 г.

Во сколько: 11:00–12:30 по мск

Формат: Онлайн

Участие: Бесплатное (нужно предварительно зарегистрироваться)

В SpaceWeb запустили новые готовые решения для VPS

Подключили в SpaceWeb три новых образа для быстрого развертывания на VPS:

• Ruby on Rails — наиболее популярный фреймворк для работы с Ruby. Для веб-приложений, API и быстрого запуска MVP-проектов;

• Zulip — серверная платформа для корпоративного обмена сообщениями с открытым исходным кодом. Альтернатива Slack с полным контролем над данными;

• DokuWiki — легковесная вики-система без базы данных. Подойдет для документации, баз знаний и внутренних корпоративных wiki.

Также в панели управления доступны свежие сборки для VPS:

• AlmaLinux 9 — стабильная и надежная альтернатива CentOS с долгосрочной поддержкой для серверов и корпоративных задач;

• Rocky Linux 9 — дистрибутив, ориентированный на продакшн-нагрузку с высокой производительностью и поддержкой современного ПО;

• MySQL 8 — популярная система управления базами данных теперь и в обновленных сборках с широким функционалом для проектов любого масштаба.

Все новые решения уже доступны для развертывания на новых и существующих VPS-серверах через панель управления на сайте SpaceWeb.

Привет! Сегодня поделюсь с вами рассказом, почему Scala-макросы могут замедлять CI не только временем компиляции. Выход из такой ситуации мы нашли не сразу, но решение оказалось настолько удачным, что наша команда решила им поделиться со всем сообществом. А дело было так…

У нас есть монорепозиторий на 4 млн LOC Scala-кода, мы собираем его в Bazel с кешированием результатов сборки, чтобы разработчики не ждали компиляцию и тестирование кода, который они не трогали. Долгое время у нас болело, что чужие тесты иногда запускались на CI.

Стали разбираться и выяснили: не весь наш код компилируется идемпотентно. Повторная компиляция одного и того же Scala-кода для многих таргетов создаёт jar-архивы с разной хэш-суммой, но семантически одинаковым содержанием. И весь зависящий от них код собирается заново. В этом виноваты Scala-макросы: при повторной компиляции кода с макросом, генерирующим sealed-иерархию, порядок перечисления наследников в байткоде может отличаться от предыдущей компиляции. Такое поведение мы обнаружили в библиотеках chimney и play-json.

То есть компиляция кода с использованием макросов из этих библиотек работала не идемпотентно и ломала кеширование сборок. Аналогичное поведение мы нашли и в одном макросе для ZLayer.

Мы сделали эти макросы детерминированными:

• Пул-реквест для chimney

• Пул-реквест для play-json

• Пул-реквест для ZLayer 

Если вы используете кеширование сборок и эти библиотеки — обновитесь до последних версий, чтобы применить эти изменения.