Отличный комментарий, не увидел этот запрос (/award_emoji) ранее. С ним можно реализовать намного больше — фильтровать лайк создателя MR, назначить тех, чьи лайки будут значимыми при подсчете голосов.
> А сколько ваш МР-пайплайн длится? У нас вот примерно полчаса, каждый раз перезапускать (а тем более когда код не менялся) — это что-то с чем-то).
Время сборки в среднем 20-30 минут. В пайплайне проверяю:
— при компиляции: если в Nexus уже есть артефакт, собранный на этот коммит, то сборка пропускается
— при сборке докер-образа: так же в Nexus проверяю наличие контейнера по хэшу коммита.
Поэтому повторные запуски (например, редеплой) укладываются в одну минуту
> Ну вы же понимаете, что от числа общая проблема не зависит?
Конечно, вы все верно написали, с командой все заранее обговорили и команде доверяем. Но с этой доработкой намного лучше в том плане, что как бы ни хотелось, нельзя по быстрому что-то вмерджить.
Все верно, но это работает у нас уже несколько месяцев и решает вопросы, которые описал в начале — мерджит и разруливает конфликты тот, кто сделал коммит, но только после код ревью.
> Т.е. у вас все пайплайны будут «красными»
Не совсем так. Обычные пайплайны, выполняющиеся по пушу (на событие коммита), будут зеленые. Красными будут только пайплайны, запущенные для проверки MR (а если точнее, то красной будет стадия проверки голосов, если к моменту проверки голосов было недостаточно. Если в стадиях сборки, тестов и т. д. ошибок не было, то остальные стадии будут зеленые)
> Поставил "+", перезапустил пайплайн, он зелененький
У нас стоит требования минимум три лайка (NEED_VOTES: 3), поэтому джун самостоятельно не сможет вмерджить, пока еще двое коллег не лайкнут
> проверяя голоса от конкретных людей
К сожалению API Gitlab не позволяет узнать, чти это голоса, иначе я бы смог сделать логику с функционалом из платной версии
По этой же схеме столкнулся с «производителем оборудования для строительства и ремонта» Fubag — описывают себя, как 40 лет на рынке, производство Германия, а по факту заурядный Китай, и никаких 40 лет на рынке нет.
Михаил, спасибо за дополнение. Включение форвардинга смотрел на официальном Wiki разработчиков CentOS wiki.centos.org/TipsAndTricks/IPForwarding
В дистрибутиве CentOS 7 нет каталога /etc/sysctl.s
Обращаю внимание на то, что не сконфигурирован keepalive. Мне так и не удалось включить ответную часть на Ubuntu. Если не будет трафика, то интерфейс на MikroTik будет «уходить» из running и подниматься, только если пойдет трафик со стороны Ubuntu.
Попробуйте использовать netwatch, отправляя пинг на Ubuntu — это будет работать вместо keepalive
Достаточно часто встречается ситуация, когда требуется организовать бесшовное покрытие большой территории и наладить управление беспроводной сетью с большим количеством точек доступа.
Добрый день. Хоть в первом предложении у вас и есть упоминание о бесшовном покрытии, но в спецификации оборудования не нашел протоколов 802.11r и 802.11k или подобных им технологий. Я правильно понимаю, что настоящей бесшовности не будет? Будет автоматическое переключение устройств с точки на точку с некоторой задержкой, как правило с прерыванием видео/аудио потока.
{
"id": 4872049,
"name": "thumbsdown",
"user": {
"id": 2801465,
"name": "Ivanov Ivan",
"username": "ivanovi",
"state": "active",
"avatar_url": "https://assets.gitlab-static.net/uploads/-/system/user/avatar/2801465/avatar.png",
"web_url": "https://gitlab.com/ivanovi"
},
"created_at": "2020-06-24T14:07:32.298Z",
"updated_at": "2020-06-24T14:07:32.298Z",
"awardable_id": 62518352,
"awardable_type": "MergeRequest"
}
Спасибо!
Время сборки в среднем 20-30 минут. В пайплайне проверяю:
— при компиляции: если в Nexus уже есть артефакт, собранный на этот коммит, то сборка пропускается
— при сборке докер-образа: так же в Nexus проверяю наличие контейнера по хэшу коммита.
Поэтому повторные запуски (например, редеплой) укладываются в одну минуту
При пуше ветки запускается пайплайн, и он должен быть зеленый (сборка, тесты). Этот пайплайн выполняется при каждом коммите.
При MR запускается пайплайн, в котором добавлен блок, выполняемый только при MR.
rules:
— if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == «master» || $CI_MERGE_REQUEST_TARGET_BRANCH_NAME =~ /^release\/.*$/'
> Ну вы же понимаете, что от числа общая проблема не зависит?
Конечно, вы все верно написали, с командой все заранее обговорили и команде доверяем. Но с этой доработкой намного лучше в том плане, что как бы ни хотелось, нельзя по быстрому что-то вмерджить.
> Т.е. у вас все пайплайны будут «красными»
Не совсем так. Обычные пайплайны, выполняющиеся по пушу (на событие коммита), будут зеленые. Красными будут только пайплайны, запущенные для проверки MR (а если точнее, то красной будет стадия проверки голосов, если к моменту проверки голосов было недостаточно. Если в стадиях сборки, тестов и т. д. ошибок не было, то остальные стадии будут зеленые)
> Поставил "+", перезапустил пайплайн, он зелененький
У нас стоит требования минимум три лайка (NEED_VOTES: 3), поэтому джун самостоятельно не сможет вмерджить, пока еще двое коллег не лайкнут
> проверяя голоса от конкретных людей
К сожалению API Gitlab не позволяет узнать, чти это голоса, иначе я бы смог сделать логику с функционалом из платной версии
Просто так править файлы в /etc/sudoers.d/ не стоит
Лучше добавить — «используя visudo»
wiki.centos.org/TipsAndTricks/IPForwarding
В дистрибутиве CentOS 7 нет каталога
/etc/sysctl.sЕсли вы имели ввиду
то поясните подробнее, в чем преимущество, поправлю в статье
Попробуйте использовать netwatch, отправляя пинг на Ubuntu — это будет работать вместо keepalive
Добрый день. Хоть в первом предложении у вас и есть упоминание о бесшовном покрытии, но в спецификации оборудования не нашел протоколов 802.11r и 802.11k или подобных им технологий. Я правильно понимаю, что настоящей бесшовности не будет? Будет автоматическое переключение устройств с точки на точку с некоторой задержкой, как правило с прерыванием видео/аудио потока.