Василий

1. Да, возможно. Поднимаете отдельный CI/CD сервер, создаете задачу с нужным вам функционалом и на этом сервере её запускаете. Отчёт можно любым приложением/скриптом отправить/залить куда и как угодно. Например, можно сразу в коммит или в запрос запостить сообщение через API: https://docs.gitlab.com/api/commits/#post-comment-...
А при появлении сообщения в коммите/запросе гитлаб автоматом оповещает всех причастных, кто подписан. Просто настройте нужные вам оповещения — можно ботом в чат их слать в ТМ, на почту или ещё куда угодно.
Так же гитлаб поддерживает стандартные форматы отчётов тестов из коробки, что позволяет сразу в интерфейсе гитлаба увидеть все результаты тестов. Возможно в вашем случае это подойдёт, возможно нет.
Отдельный сервер нужен для того, чтобы не создавать проблемы и тормоза на основном сервере, где запущен гитлаб. А если запускаете на том же — убедитесь в установке ограничений производительности для задач. Иначе, когда у вас будет запускаться по сотне или даже тысяче задач в день — будет не очень комфортно работать с гитлабом.

2. Это не имеет смысла. Пуш — это по факту просто загрузка коммита на сервер. Есть PR — он легко блокируется через подтверждение со стороны определённых пользователей или групп пользователей, а так же в случае если задача завершилась с ошибкой. Это всё настраивается в настройках. Вам следует просто правильно организовать рабочий процесс. Используйте стандартный Github Flow. PR для того и придуманы, чтобы в PR принимать или отклонять изменения. Не, так-то если очень хочется, то можно откатывать одиночные коммиты, но правильнее это делать через PR.

3. Задача запускается сразу после пуша. В задаче есть полный доступ к репозиторию и всему коду. А т.к. это гит, то легко можно получить все изменения в любом виде в скрипте и делать что угодно с ними.

4. Да, это стандартное поведение всех задач. Задача, обычно, запускается в контейнере и пока контейнер работает — статус задачи не меняется. Либо это отдельный скрипт на сервере, завершение которого гитлаб будет ждать. Задачу даже можно разбить на несколько стадий и по мере их завершения менять статус самой задачи, а результат можно даже в реальном времени в самом гитлабе в задаче наблюдать.

у меня на похожем стеке (symfony + react, но суть та же) просто отдельный docker-compose.test.yml где бэк стартует с APP_ENV=test, а фронту кидаешь нужные env через .env.test. поднимаешь рядом на других портах и cypress бьёт туда. не пытайся переключать env у запущенного стека — проще поднять второй рядом

Ну, наверное, потому, что тип поля CHAR(1) - то есть более одного символа в поле тупо не помещается.

Есть :)

Законодательство РФ. Особенно то, что касается авторских прав, персональных данных и преступлений в сфере ИТ (взломов и т.д.)

Вопрос - а зачем тут вообще нужен Ticker?

Может быть против "дребезга контактов") На случай если ввиду каких либо причин сигналы m.triggerReload начнут сыпаться как из ведра (с оглушительной частотой)

Тяжело наверное, когда во всех поисковиках забанили, да?

https://docs.iredmail.org/fail2ban.sql.html

ВСЕМ СПАСИБО, кто ответил. Решил следующим образом на Виндовом контроллере домена сделал запрет по MAC для конкретного оборудования и разрешения для всего остального зарезервированного. После этого поднял DHCP на роутере с выделением 5 IP адресов (10.1.10.101-105) и добавил их в ограничения IP и с контроллера домена перестала прилетать раздача на целевое железо, а стали прилетать с роутера с необходимым IP. При этом внутренние ресурсы работают как надо, т.к. он находится в одной подсети

Инкапсуляция защищает не от хакеров, а от неправильного использования объектов.
Как пример - у тебя может быть класс "Заказ" и у него может быть какой-то статус (оплачен/ждёт оплаты/отменён итд).
При этом у тебя могут быть правила типа: уже оплаченный заказ не может стать вдруг неоплаченным, а отменённый заказ нельзя взять обратно в работу.
Тогда логично будет сделать поле статуса приватным (не доступным для изменения извне напрямую), а менять его только через методы, где будет происходить вся валидация.
(В некоторых языках такие правила принято описывать на уровне типов, чтобы даже валидаций никаких было делать не нужно)

Приватные поля объекта - это его состояние.
Методы объекта - это способы его использования.

Если у тебя в объекте появляется поле x и методы getX / setX (или авто геттеры/сеттеры в C#), то значит, что у тебя и нет явных причин делать это поле приватным, кроме соблюдения общепринятых соглашений.