Как по мне это уже какая-то дискриминация мужчин. Без феминизма здесь явно не обошлось.
Вот почему к мужчине и женщине нужно обращаться она? Если судить по справедливости, то нужно к мужчинам обращаться она, а к женщинам он… Хотя этим вариантом я тоже не был бы доволен
А если я заставлю мою ОС думать, что сейчас 1941й год?
Надеюсь мне такой скрипт напишет, что еще не родился, а то «исполнился -1 год» звучит не очень круто
Насколько я слышал POI очень любит кушать оперативную память. Не замечали ли вы за ним такое, и не отслеживали колличество используемой оперативной памяти в зависимости от сложности шаблона?
Хм, не сталкивался. Знаю, что один и тот же проект в очередь больше двух раз не встанет, но разные проекты становятся в очередь «без потерь».
средства дженкинса(а может и какие-то плагины точно не скажу) позволяют определять максимальное количество запланированных сборок. Я не уверен, но вроде как возможно запретить планировать сборки в принципе.
Если это удобнее чем тот вариант, который описал я, то однозначно нужно.
из того что могу сказать по памяти — был нехороший опыт с LDAP логинами. Ну и наиболее удобный мне способ, позволял определять правила не для каждого проекта, а для группы проектов названия которых совпадают с регулярным выражением(еще один плюс в пользу структурированных названий проектов)
Если сборка проекта не однопоточнная, то за ней можно закрепить большее число executor'ов.
Если вы создадите большее число executor'ов чем количество ядер на вашем сервере, то, на мой взгляд, ваши проекты хоть и начнут собираться одновременно, но закончат они все-равно не раньше чем если бы они были запущенны один за другим.
Тут скорее нужно бояться не длительности выполнения, а возможности невыполнения сборки. У нас ограниченное максимальное число запланированных сборок, и соответственно возможна ситуация, когда некоторые сборки будут проигнорированы, хот\ это и маловероятно.
обратите внимание на multi-configuration project, возможно это позволит сократить число проектов и сгруппировать их
От мультиконфигураций отказались осознанно. Например на дженкинсе у нас запускаются тестовые сервера, и нам нужно уметь запускать конкретные сервера(конкретные бренчи) по требованию, а не сразу все. Более того в силу особенностей — это бесконечные сборки(подробнее ниже), и останавливать один сервер, что бы запустить два — не рационально.
Вообще ничего не понял. Возможно сказывается тот факт, что я не знаком с Java, но я никак не могу понять для каких задач может потребоваться такое? «которые можно было завершить только по нажатию крестика», — а как разработчики у себя на рабочих машинах собирают эти проекты?
Средства джава позволяют запускать подобные проекты и другими способами, просто гораздо удобнее читать основной лог веб сервера в логе сборки и на ходу понимать что к чему, чем копаться по логам сохраненным на сервере(выгрузить как артефакты их не удастся), к которому не у всех есть доступ.
ну а по поводу безопасности у дженкинса реализован отличнейший функционал плагинов, позволяющих быстро и удобно определять политику пользователей. Если интересно — могу более подробно написать
Если сборка проекта не однопоточнная, то за ней можно закрепить большее число executor'ов.
Если вы создадите большее число executor'ов чем количество ядер на вашем сервере, то, на мой взгляд, ваши проекты хоть и начнут собираться одновременно, но закончат они все-равно не раньше чем если бы они были запущенны один за другим.
Тут скорее нужно бояться не длительности выполнения, а возможности невыполнения сборки. У нас ограниченное максимальное число запланированных сборок, и соответственно возможна ситуация, когда некоторые сборки будут проигнорированы, хот\ это и маловероятно.
Обратите внимание на multi-configuration project, возможно это позволит сократить число проектов и сгруппировать их.
Вот почему к мужчине и женщине нужно обращаться она? Если судить по справедливости, то нужно к мужчинам обращаться она, а к женщинам он… Хотя этим вариантом я тоже не был бы доволен
Надеюсь мне такой скрипт напишет, что еще не родился, а то «исполнился -1 год» звучит не очень круто
средства дженкинса(а может и какие-то плагины точно не скажу) позволяют определять максимальное количество запланированных сборок. Я не уверен, но вроде как возможно запретить планировать сборки в принципе.
из того что могу сказать по памяти — был нехороший опыт с LDAP логинами. Ну и наиболее удобный мне способ, позволял определять правила не для каждого проекта, а для группы проектов названия которых совпадают с регулярным выражением(еще один плюс в пользу структурированных названий проектов)
Тут скорее нужно бояться не длительности выполнения, а возможности невыполнения сборки. У нас ограниченное максимальное число запланированных сборок, и соответственно возможна ситуация, когда некоторые сборки будут проигнорированы, хот\ это и маловероятно.
От мультиконфигураций отказались осознанно. Например на дженкинсе у нас запускаются тестовые сервера, и нам нужно уметь запускать конкретные сервера(конкретные бренчи) по требованию, а не сразу все. Более того в силу особенностей — это бесконечные сборки(подробнее ниже), и останавливать один сервер, что бы запустить два — не рационально.
Средства джава позволяют запускать подобные проекты и другими способами, просто гораздо удобнее читать основной лог веб сервера в логе сборки и на ходу понимать что к чему, чем копаться по логам сохраненным на сервере(выгрузить как артефакты их не удастся), к которому не у всех есть доступ.
ну а по поводу безопасности у дженкинса реализован отличнейший функционал плагинов, позволяющих быстро и удобно определять политику пользователей. Если интересно — могу более подробно написать
Тут скорее нужно бояться не длительности выполнения, а возможности невыполнения сборки. У нас ограниченное максимальное число запланированных сборок, и соответственно возможна ситуация, когда некоторые сборки будут проигнорированы, хот\ это и маловероятно.
Обратите внимание на multi-configuration project, возможно это позволит сократить число проектов и сгруппировать их.www.velobike.ru