Pull to refresh
25
0
Send message
У нас ограниченное максимальное число запланированных сборок, и соответственно возможна ситуация, когда некоторые сборки будут проигнорированы,
Хм, не сталкивался. Знаю, что один и тот же проект в очередь больше двух раз не встанет, но разные проекты становятся в очередь «без потерь».

ну а по поводу безопасности у дженкинса реализован отличнейший функционал плагинов, позволяющих быстро и удобно определять политику пользователей. Если интересно — могу более подробно написать
Если это удобнее чем тот вариант, который описал я, то однозначно нужно.
Статьи про CI, а тем-более про Jenkins это всегда здорово!

Не стоит устанавливать все plugin'ы которые видите.… Они могут… съедать лишние ресурсы… .

Кроме того после установки практически каждого plugin'a расширяются системные настройки и/или настройки проекта, что может усложнить процесс настройки для начинающего пользователя. Опираясь на свой незначительный опыт могу сказать, что незнакомые plugin'ы однозначно удобнее устанавливать по одному, особенно (!) если это plugin'ы схожи по назначению.

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

На мой взгляд выгода от данной рекомендации весьма сомнительна. По умолчанию Jenkins создает executer'ов по количеству ядер, что (при однопоточной сборке проектов) позволяет исключить взаимное влияние на наличие ресурсов между одновременно запущенными проектами. Если сборка проекта не однопоточнная, то за ней можно закрепить большее число executor'ов.
Если вы создадите большее число executor'ов чем количество ядер на вашем сервере, то, на мой взгляд, ваши проекты хоть и начнут собираться одновременно, но закончат они все-равно не раньше чем если бы они были запущенны один за другим.

Безопасность. Не стоит о ней забывать. ...

Однозначно полезный совет. Касательно безопасности хочется добавить, что помимо настройки глобальных прав Jenkins позволяет «уточнять» права индивидуально для каждого проекта и я бы рекомендовал сразу же следовать этой практике. Т.е. глобально всем пользователям (кроме админа) уровень Read, а вот уже на каждом отдельном проекте индивидуально для каждого пользователя устанавливаются конкретные права; в 99% случаев для всех пользователей от проекта к проекту права будут одинаковы, но когда наступит тот самый 1%, то такой подход себя оправдает!

Например, если у вас несколько версий одного продукта запущены на разных портах, почему бы их не назвать в духе «ProjectAbbr9587», где 9587 — это номер порта. Такая политика имен, позволяет быстро понять, и уменьшает возможность перепутать о чем идет речь.

Обратите внимание на multi-configuration project, возможно это позволит сократить число проектов и сгруппировать их.

Естественно после первого запуска мне было непривычно смотреть на синие кружечки, но их цвет был изменен далеко не сразу.

Все правильно! Синие кружочки это моветон! Кружочки должны быть исключительно зелеными ;)!

С другой стороны, у меня были проекты, которые должны находиться в «бесконечной сборке». Ant task'и, которые запускали веб сервера и в сборку выводили лог действий, что было очень удобно. Естественно эти сервера могли находиться по несколько дней в запущенном состоянии, и без лишней надобности их останавливать нет смысла, т.к. на них могут вестись работы, показываться результаты заказчикам и прочее.
Допустим из-за скачка напряжения\отсутствия света сервер перезагрузили. На нем запустился JenkinsCI, но не запустились проекты, которые должны быть постоянно запущены? Каждый раз запускать ручками — глупо. Так что, очень хочется галочку: «запускать ли данный проект, после перезагрузки?»
Т.к. у меня были проекты, которые можно было завершить только по нажатию крестика(что означает «отмена сборки»), меня очень сильно угнетали серые шарики, по этому мне захотелось сделать сборку успешной(пусть не портит статистику, я же знаю, что все правильно).

Вообще ничего не понял. Возможно сказывается тот факт, что я не знаком с Java, но я никак не могу понять для каких задач может потребоваться такое? «которые можно было завершить только по нажатию крестика», — а как разработчики у себя на рабочих машинах собирают эти проекты?
Тогда уж сразу KDbg.
> Вы путаете бенчмаркинг ради бенчмаркинга и бенчмаркинг ради практического результата.
Я не являюсь специалистом, но мне кажеться, что Вы путаете бенчмаркинг и профилирование.
Мне это знание за тем, что бы я мог сказать, что алгоритм (или реализация) «А» быстрее алгоритма «В».
Другое дело если мне нужен ответ на вопрос: «как долго выполняется алгоритм „А“ в реальном проекте и сколько это в процентах от общего времени (т.е. профилировка)?», — тогда я согласен, условия при которых производятся измерения должны быть максимально приближены к «боевым».
> Если мы хотим использовать этот код в продакшене,
Не хотим. Речь идет о benchmark'ах.
> Но очень странная идея — использовать минимум в погоне за маленькой дисперсией.
Выбор наименьшего значения по результатам огромного повторения — это попытка определить время выполнения именно того участка кода, который нас интересует и нивелировать потери на кэш-промахи, переключения контекста и т.п.
Тем более, что там даже какой-то SIMD есть.
Просто кто-то в детстве вместо того, что бы из медной трубки делать самопал на с деревянной рукояткой красноглазил за компом, а теперь вот велосипед изобретает :).

Согласен, если пистолет гладкоствольный и не самозарядный, то профита от него крайне мало.
Спасибо, действительно не заметил отступ… Хотя смысл рекомендации для меня очевиднее не стал.

Кстати, некоторые рекомендации можно было бы поправить с учетом С++11, например:
— 31. Константы в перечислениях могут иметь префикс — общее имя типа: используйте enum class;
— 66. Константы с плавающей точкой следует записывать с десятичной точкой и с указанием по крайней мере одной цифры после запятой: используйте литералы;
— 70. Следует использовать «0» вместо «NULL»: используйте nullptr.
Никак не могу уловить суть рекомендации 93. Комментарии следует располагать так, чтобы они относились к тому, что они описывают.
Мне кажется, что в примере оба варианта (рекомендуемый и не рекомендуемый) одинаковы. Или я чего-то не замечаю…
Linux не хватает хорошего офисного Visio.
Скорее: «Работает — не трогай» (с).
Браузер — лучше сразу застрелиться.

Для web'a же есть прекрасный Selenium!
По умолчанию поведение следующее:
1. Первая задача после старта при наличии свободных ресурсов (ноды) немедленно выполняется.
2. Вторая задача становиться в очередь, т.к. ресурсы (ноды) заняты.
3. Третья и последующие задачи «сбрасываются» и в очередь не становятся.

Т.е. реализована очередь на одну задачу.

Т.о. пока не завершиться предыдущая задача, следующая выполнятся не будет, а будет ожидать в очереди.
Просто к слову.
> Требует Java. Как на мастере, так и на нодах.
Раньше для разворачивания ноды пробрасывал ssh, все остальное Jenkins делал сам (скачивал JDK из Интернетов), а буквально месяц назад разворачивал ноду и столкнулся с тем, что теперь для скачивания JDK необходимо иметь аккаунт у Oracle… Подумав, решил поставить openJDK вручную.
Jenkins может запускать сборку вручную, по расписанию, а так же по расписанию но при условии, что были изменения в системе контроля версий.
Расписание можно устанавливать так же гибко, как и в cron'е, например:
— «Собирать каждый час при наличии изменений»;
— «Собирать в 03.00 каждый четверг»;
— и т.п.
> Явно выраженный обратный лепесток
> боковых лепестков

Меня именно обратный интересовал. Но судя по ответу в ФАР нет боковиков вообще? А приведенная схема ДНА тогда к чему относиться?
Явно выраженный обратный лепесток ДНА это частный случай обусловленный использованием ФАР или это свойтственно для всех антенн с направленной ДНА?
Не более чем писать в начале скриптов:
#!/bin/sh
На С# в Linux можно тоже скрипты писать:

gluttton@lx:~> cat > script.sh << EOF
> #!/usr/bin/csharp
> 
> System.Console.WriteLine ("Bingo!");
> EOF
gluttton@lx:~> chmod +x script.sh
gluttton@lx:~> ./script.sh 
Bingo!
gluttton@lx:~>

Information

Rating
Does not participate
Location
Феодосия, Республика Крым, Россия
Date of birth
Registered
Activity