Здравствуйте, karbofos42, Вы писали:

K>·>Что за обработка?? Это называется peer review. И PR будет в любом случае. Вопрос сколько ручного труда потребуется для создания этого PR. По уму этот PR создаётся автоматически. У тебя этим придётся заниматься тебе — почитать логи билда, найти там варнинги. Выкачать проект локально, прописать новую версию зависимости, закоммитить, запушить и получить в итоге ровно тот же PR, который всё равно нужно так же "обрабатывать", что бы это ни значило.
K>А у тебя что в автоматическом PR будет? Изменение в файле проекта, что изменилась версия какой-то библиотеки и ты это будешь смотреть и ревьюить?
Да. И в описании PR будет этот самый варнинг NU1903.

K>·>А кто эти запросы будет составлять и посылать? И зачем?
K>А кто скачивает индексы из репозитория на локальную машину?
K>Кто периодически запрашивает у репозитория новые индексы?
IDE.

K>Кто составляет запросы к этим локальным индексам?
Редактор кода в IDE.

K>А зачем всё это делать, если можно это возложить на репозиторий?
Репозиториев может быть несколько. Запросы надо слать ко всем. Это будет тормозить. И представь себе какая должна быть мощная инфра.

K>·>Тогда обычно работники пушат исходник в твой гит и оттуда всё собирается у тебя, если у подрядчика нет инфры.
K>Чьи работники пушат в мой гит?
K>С чего вдруг у подрядчика, который занимается разработкой ПО, нет своей инфраструктуры?
Ты так написал.

K>·>Ну ламеры, что сказать. Тут никакой инструмент не поможет. С таким же успехом чувак без всякого msbuild restore/publish мог собирать локально, зависимости держать в C:\TEMP и слать вам бинари почтой на сидюке.
K>Только что ты говорил, что самому у себя собирать неправильно.
K>Цитаты:
K>"Обычно по-другому делается — ты билдишь у себя, а клиентам даёшь доступ к своему репо — он оттуда и тянет всё готовенькое."
K>"Эээ.. что за хрень? А какой-нибудь Newtonsoft.Json у себя на серверах собираешь? И Студию?"
Это обычно так. У тебя какой-то вырожденный случай наёмных работников через третьих лиц.

K>·>Я это к тому, что инструментально это никак не проверяется. Если вы получаете только бинари, а исходники только по актам.
K>Исходники получали вместе с бинарниками, только ведь проект не на убогом .NET с NuGet, а нормальный Java + maven.
K>Зачем самим у себя собирать, если разработчики готовые бинарники дают? Или всё же внезапно нужно у себя собирать, а не надеяться на сторонних разработчиков с их инфраструктурой?
Верно — в обычных случаях это правильный подход. Ведь ты Newtonsoft.Json и много других либ берёшь в виде бинарников, и не жужжишь.

K>·>Ну это у школьников только такие проблемы. Исходники собираются на билд-серверах, и раз билд-сервер смог (не важно чей) собрать, то смерть тут не проблема.
K>Ну, где-то на чьих-то билд-серверах они собираются, мне то с этого что, если этого сервера у меня нет?
Почему тебя Newtonsoft билд-сервера не беспокоят?

K>·>Да, при подписании-то актов о приёмке специалисты куда-то потерялись.
K>Так эти "специалисты" считали, что не нужно самим собирать, а нормально проверять только готовые бинарники.
K>К бинарникам проблем и не было.
Ну что хотели, то и получили. Не вижу чего их не устраивает.

K>·>ИЧСХ, даже в такой откровенно идиотской ситуации вы смогли за неделю всё восстановить. Ложечки-то нашлись!
K>Ага. Только пришлось и инфраструктуру поднимать и код править. Потому что у кого-то где-то билд-сервер это собирал, вот у нас же есть все pom.xml, в которых вся нужная документация для сборки и ничего больше не надо.
Э. И? Если вы никогда не собирали и у вас ничего для сборки никогда не было — как оно у вас магически появится? Хоть с mvn, хоть с msbuild? В следующий раз впишите в акт приёмки docker-image билд-сервера.

K>·>Ты заявлял, что он зафиксирован не в проекте, а в твоих локальных настройках нугета. Ты уж определись.
K>У меня внезапно есть проекты как на .NET, так и на Java.
K>В Java-проекте вот репозиторий прописан в pom.xml, т.к. во всех книгах и примерах так пишут и какие соседние проекты смотрел — такая же фигня.
K>Так чем мне помогает документация в виде фиксации репозитория в pom.xml, если сейчас во всех проектах это нужно переделывать, т.к. админы решили другой репозиторий развернуть?
А какая альтернатива? Переделывать на всех локальных машинах и билд-серверах?

K>·>Ну в mvn можно переопределить через командную строку. И все эти "не тот репозиторий" есть в git-истории проекта — все ходы записаны.
K>И на каждый чих в итоге лезь и разбирайся как это сделать.
K>Сначала вроде разобрался как в pom.xml указывать, потом разбирайся как через командную строку перегрузить. Очень удобно и продуктивно.
А что ты предлагаешь? Порыться в емейлах и найти где там предыдущий разработчик рассказывал что куда надо делать?

K>·>Потому что не через GUI работать сложнее и многие автоматизируемые действия приходится делать вручную.
K>Кому сложнее, а кому удобнее.
K>Автоматизацией занимаются далеко не все.
K>Скорее всего, кто-то один на проекте это всё будет настраивать, а у остальных просто всё работает.
K>И так происходит что в Java, что в .NET, что в остальных проектах.
K>Или будут сказки о том, что все разработчики, использующие maven, умеют не только зависимости добавлять и копипастить что-то из интернетов, но и сами легко плагин напишут и реализуют сложный сценарий сборки?
А какие варианты-то? Сложный сценарий сборки появится магически? Но в целом да, вики-страничку с инструкцией наот**ись написать проще, чем плагин.

Здравствуйте, karbofos42, Вы писали:

K>·>Что за обработка?? Это называется peer review. И PR будет в любом случае. Вопрос сколько ручного труда потребуется для создания этого PR. По уму этот PR создаётся автоматически. У тебя этим придётся заниматься тебе — почитать логи билда, найти там варнинги. Выкачать проект локально, прописать новую версию зависимости, закоммитить, запушить и получить в итоге ровно тот же PR, который всё равно нужно так же "обрабатывать", что бы это ни значило.
K>А у тебя что в автоматическом PR будет? Изменение в файле проекта, что изменилась версия какой-то библиотеки и ты это будешь смотреть и ревьюить?
Да. И в описании PR будет этот самый варнинг NU1903.

K>·>А кто эти запросы будет составлять и посылать? И зачем?
K>А кто скачивает индексы из репозитория на локальную машину?
K>Кто периодически запрашивает у репозитория новые индексы?
IDE.

K>Кто составляет запросы к этим локальным индексам?
Редактор кода в IDE.

K>А зачем всё это делать, если можно это возложить на репозиторий?
Репозиториев может быть несколько. Запросы надо слать ко всем. Это будет тормозить. И представь себе какая должна быть мощная инфра.

K>·>Тогда обычно работники пушат исходник в твой гит и оттуда всё собирается у тебя, если у подрядчика нет инфры.
K>Чьи работники пушат в мой гит?
K>С чего вдруг у подрядчика, который занимается разработкой ПО, нет своей инфраструктуры?
Ты так написал.

K>·>Ну ламеры, что сказать. Тут никакой инструмент не поможет. С таким же успехом чувак без всякого msbuild restore/publish мог собирать локально, зависимости держать в C:\TEMP и слать вам бинари почтой на сидюке.
K>Только что ты говорил, что самому у себя собирать неправильно.
K>Цитаты:
K>"Обычно по-другому делается — ты билдишь у себя, а клиентам даёшь доступ к своему репо — он оттуда и тянет всё готовенькое."
K>"Эээ.. что за хрень? А какой-нибудь Newtonsoft.Json у себя на серверах собираешь? И Студию?"
Это обычно так. У тебя какой-то вырожденный случай наёмных работников через третьих лиц.

K>·>Я это к тому, что инструментально это никак не проверяется. Если вы получаете только бинари, а исходники только по актам.
K>Исходники получали вместе с бинарниками, только ведь проект не на убогом .NET с NuGet, а нормальный Java + maven.
K>Зачем самим у себя собирать, если разработчики готовые бинарники дают? Или всё же внезапно нужно у себя собирать, а не надеяться на сторонних разработчиков с их инфраструктурой?
Верно — в обычных случаях это правильный подход. Ведь ты Newtonsoft.Json и много других либ берёшь в виде бинарников, и не жужжишь.

K>·>Ну это у школьников только такие проблемы. Исходники собираются на билд-серверах, и раз билд-сервер смог (не важно чей) собрать, то смерть тут не проблема.
K>Ну, где-то на чьих-то билд-серверах они собираются, мне то с этого что, если этого сервера у меня нет?
Почему тебя Newtonsoft билд-сервера не беспокоят?

K>·>Да, при подписании-то актов о приёмке специалисты куда-то потерялись.
K>Так эти "специалисты" считали, что не нужно самим собирать, а нормально проверять только готовые бинарники.
K>К бинарникам проблем и не было.
Ну что хотели, то и получили. Не вижу чего их не устраивает.

K>·>ИЧСХ, даже в такой откровенно идиотской ситуации вы смогли за неделю всё восстановить. Ложечки-то нашлись!
K>Ага. Только пришлось и инфраструктуру поднимать и код править. Потому что у кого-то где-то билд-сервер это собирал,
Э. И? Если вы никогда не собирали и у вас ничего для сборки никогда не было — как оно у вас магически появится? Хоть с mvn, хоть с msbuild? В следующий раз впишите в акт приёмки docker-image билд-сервера.

K>вот у нас же есть все pom.xml, в которых вся нужная документация для сборки и ничего больше не надо.
Ну да. У вас ничего больше и не было, и у вас таки всё заработало через неделю. ЧТД.

K>·>Ты заявлял, что он зафиксирован не в проекте, а в твоих локальных настройках нугета. Ты уж определись.
K>У меня внезапно есть проекты как на .NET, так и на Java.
K>В Java-проекте вот репозиторий прописан в pom.xml, т.к. во всех книгах и примерах так пишут и какие соседние проекты смотрел — такая же фигня.
K>Так чем мне помогает документация в виде фиксации репозитория в pom.xml, если сейчас во всех проектах это нужно переделывать, т.к. админы решили другой репозиторий развернуть?
А какая альтернатива? Переделывать на всех локальных машинах и билд-серверах?

K>·>Ну в mvn можно переопределить через командную строку. И все эти "не тот репозиторий" есть в git-истории проекта — все ходы записаны.
K>И на каждый чих в итоге лезь и разбирайся как это сделать.
K>Сначала вроде разобрался как в pom.xml указывать, потом разбирайся как через командную строку перегрузить. Очень удобно и продуктивно.
А что ты предлагаешь? Порыться в емейлах и найти где там предыдущий разработчик рассказывал что куда надо делать?

K>·>Потому что не через GUI работать сложнее и многие автоматизируемые действия приходится делать вручную.
K>Кому сложнее, а кому удобнее.
K>Автоматизацией занимаются далеко не все.
K>Скорее всего, кто-то один на проекте это всё будет настраивать, а у остальных просто всё работает.
K>И так происходит что в Java, что в .NET, что в остальных проектах.
K>Или будут сказки о том, что все разработчики, использующие maven, умеют не только зависимости добавлять и копипастить что-то из интернетов, но и сами легко плагин напишут и реализуют сложный сценарий сборки?
А какие варианты-то? Сложный сценарий сборки появится магически? Но в целом да, вики-страничку с инструкцией наот**ись написать проще, чем плагин.