Здравствуйте, karbofos42, Вы писали:
K>·>Как это согласуется с "Мне не нужны последние версии библиотек"? Т.е. не нужно, но очень хочется...
K>Мне не нужно автоматически обновлять библиотеки в существующих проектах, но предпочитаю в новых проектах изначально брать последние версии.
K>В существующих обновление версии может привести к необходимости допиливания и на это нужно время.
K>В новых ломаться пока ещё нечему и сразу пишешь на последней версии, т.к. там исправлены баги или что-то новое добавлено, что может пригодиться.
Т.е. личные предпочтения и заморочки. Т.е. не нужно, но очень хочется. Ну тут наука бессильна.
K>·>Ну не подтягивай. Я тебе уже показал как можно вручную проверить локально наличие свежего, без автоджобов.
K>Напоминаю, что речь шла о том, что в Nuget это всё есть изначально, без "вручную".
GUI — это вручную, по определению.
K>·>Как реагировать-то? Вручную? И кто эти варнинги читает и обращает внимание? Это должен быть не варнинг, а PR висящий для ревью.
K>Можно настроить, чтобы варнинги считались ошибками и тогда такое не соберётся и придётся реагировать.
Это будет сломанный билд и шоустоппер. Спасибо, не надо.
K>А обработка PR — это не вручную?
Что за обработка?? Это называется peer review. И PR будет в любом случае. Вопрос сколько ручного труда потребуется для создания этого PR. По уму этот PR создаётся автоматически. У тебя этим придётся заниматься тебе — почитать логи билда, найти там варнинги. Выкачать проект локально, прописать новую версию зависимости, закоммитить, запушить и получить в итоге ровно тот же PR, который всё равно нужно так же "обрабатывать", что бы это ни значило.
K>А править работу с библиотекой, если в новой версии интерфейсы поменялись и устарели используемые методы — это не вручную?
Именно, что _если_.
K>Чего мне в PR ревьюить, если изменение версии библиотеки — это просто в одном файле цифра поменялась и это справедливо и для MSBuild и для maven и для gradle?
Ну можешь и автомерж сделать, если очень хочется.
K>·>Никак. Ты контекст потерял.
K>По-моему это ты потерялся в своих автоматизациях, которые вручную нужно делать.
Нет. Перечитай, тут все ходы записаны.
K>·>Нормально это как? Вручную?
K>Я уже писал: научить репозиторий запросам поиска,
А кто эти запросы будет составлять и посылать? И зачем?
K>чтобы этим всем он занимался, а не каждый клиент выкачивал себе индексы и что-то там с ними делал.
Я уже отвечал. Это делает versions update — смотрит последние версии зависимостей проекта и сообщает что есть нового. Индексы нужны для быстрого набора кода.
K>·>Ну за Студию-то платишь, надеюсь. И вполне вероятно, что используешь платные библиотеки.
K>За исходники студии не плачу. Мне серьёзно вот нужно пояснять разницу между покупкой массового продукта и оплатой разработки под свои хотелки?
Тогда обычно работники пушат исходник в твой гит и оттуда всё собирается у тебя, если у подрядчика нет инфры.
K>·>Непонятно, почему починкой этого не занялся подрядчик.
K>Потому что он прекратил своё существование или с ним не захотели продлевать договор.
K>По документам они всё давно предоставил, акты все подписаны, претензий нет.
K>По факту никто не проверял исходники и что им предоставляли.
K>Подрядчик же присылал собранные бинарники, они работали — значит всё хорошо же, зачем процесс контролировать и думать о возможности собрать самому или другому подрядчику?
Ну ламеры, что сказать. Тут никакой инструмент не поможет. С таким же успехом чувак без всякого msbuild restore/publish мог собирать локально, зависимости держать в C:\TEMP и слать вам бинари почтой на сидюке.
K>·>Можно, но не нужно в общем случае. Часто не нужно билды настраивать у себя, так изредка проверить локально, что собирается, если доверия к качеству подрядчика нет.
K>Ага. И бэкапы нужно иногда только делать, ведь мы покупаем качественное железо и доверяем ему.
Я это к тому, что инструментально это никак не проверяется. Если вы получаете только бинари, а исходники только по актам.
K>или у него всё железо изъяли или единственный его разработчик заболел и умер и теперь некому билд сделать в короткие сроки.
Ну это у школьников только такие проблемы. Исходники собираются на билд-серверах, и раз билд-сервер смог (не важно чей) собрать, то смерть тут не проблема.
K>Нормальные люди взвешивают риски, продумывают возможные сценарии, а из этого потом рождаются задания техническим специалистам, которые всё это реализуют и решают появляющиеся технические проблемы.
Да, при подписании-то актов о приёмке специалисты куда-то потерялись.
ИЧСХ, даже в такой откровенно идиотской ситуации вы смогли за неделю всё восстановить. Ложечки-то нашлись!
K>·>Это знание зафиксированно в исходнике. Админы у себя баги поправят и ты в исходнике это всё поправишь и будет всё работать по уму, а не через одно место.
K>·>Если этого не будет в исходнике, то кто и как об этом будет знать? Куда и как деплоить? Откуда брать зависимости? Как поддерживать и валидировать актуальность этой инфы?
K>Какое знание где зафиксировано?
Куда и как деплоить. Откуда брать зависимости. Как поддерживать и валидировать актуальность этой инфы.
K>У меня в проекте зафиксирован репозиторий, который жив и работает.
Ты заявлял, что он зафиксирован не в проекте, а в твоих локальных настройках нугета. Ты уж определись.
K>Только по факту нужно прописать другой репозиторий, о котором мне никто ничего не сказал и я не знал о его существовании.
K>Они могли старый репозиторий отключить и я бы сидел с ошибкой, что нет доступа к репозиторию.
K>Теперь в десятке проектов нужно будет менять репозиторий, а если я захочу собрать старую версию ПО, то придётся опять мудрить, т.к. там не тот репозиторий прописан.
Ну в mvn можно переопределить через командную строку. И все эти "не тот репозиторий" есть в git-истории проекта — все ходы записаны.
K>·>Ну я говорю, что это не обязательно. Репозитории можно в разных местах определять.
K>Ну, вот Nuget плохой, т.к. с ним чаще работают через GUI.
Потому что не через GUI работать сложнее и многие автоматизируемые действия приходится делать вручную.
K>Значит maven плохой, т.к. чаще репозитории прописывают в pom.xml, а не выносят во внешние файлы 
Это не беда. Если прописанное не работает — значит неактуальная инфа, не повезло, придётся делать то, что делаешь ты сейчас постоянно — выяснить где-то как-то актуальную инфу и вписать её.
