Приходилось ли работать с закрытыми Maven репозиториями, требующими авторизацию?
Что проверяют
Автотесты на Java собираются тем же сборщиком, что и продукт, и тянут зависимости из внутреннего репозитория. Интервьюер выясняет, не встанет ли кандидат, когда сборка падает не из-за теста, а из-за доступа, и понимает ли он, где живут учётные данные.
Как отвечать
Объясните схему. Репозиторий объявляется в pom.xml или задаётся зеркалом, а логин и пароль лежат отдельно, в файле settings.xml в каталоге .m2, в секции servers. Связываются они по идентификатору: id сервера обязан совпадать с id репозитория или зеркала, иначе учётные данные просто не подставятся.
Дальше о безопасности и о запуске в CI:
- пароль в открытом виде не хранят: либо шифрование средствами сборщика с мастер-паролем, либо подстановка из переменных окружения;
- у агента сборки свой пользователь и свой кэш, поэтому конфигурацию передают явным ключом
-s, а не рассчитывают на домашний каталог; - в образ для тестов файл настроек монтируют, а не копируют слоем, чтобы секрет не остался в истории образа.
Покажите навык диагностики: подробный лог через -X, разница между ответами сервера, когда учётные данные не приняты, прав не хватает или артефакта нет вовсе, обновление снапшотов ключом -U и чистка битых записей в локальном кэше.
Где спотыкаются
Кладут файл настроек с логином и паролем в репозиторий проекта. Секрет уезжает в историю, и отозвать его потом дороже, чем сразу настроить подстановку из переменных окружения.
Не сводят идентификаторы. Учётные данные заданы, но id сервера и репозитория различаются, доступ не подставляется, и человек часами ищет причину в сети или в правах, хотя дело в одной строке конфигурации.
Объясняют разницу локальной и серверной сборки магией. Локально всё работает из прогретого кэша и личных настроек, на агенте нет ни того ни другого. Перезапуск задачи это не решение: нужно передать настройки и понять, откуда вообще берётся зависимость.