Запускать линтеры на PR

[igoose1]

В новых PR иногда бывает некрасивый код. Сейчас незаметно запускается flake8, но его ошибки игнорируются. Получаем такое:

1. Ревьюерам иногда приходится тратить время на "поставь, пожалуйста, тут пробел",
2. Ревьюеры иногда что-то не замечают, апрувят и в кодобазу летит код не по PEP8.

Сделайте так, чтобы перед ревью автору приходили "❌ Build failed" и ответственность за хороший код была на нем.

[sfuerte]

это лучше делается by shifting left, через pre-commit hooks, например #1164

[igoose1]

это лучше делается by shifting left, через *pre-commit* hooks, например #1164[#1164]

Это проблемное решение. Контрибьютеры, бывает, пишут PR даже в веб-интерфейсе. Они не запустят pre-commit хук, а Github Actions это тоже не сделает (не вижу такого конфига). В итоге, где-то будет визжать flake8, но на него никто не глянет и плохой код замержат. Чтобы плохой код не замержился, можно: 1. Либо показывать красным крестиком и надписью "pipeline failed", что PR не готов, 2. Либо не мержить никакой код (как сейчас).

[sfuerte]

Это не "проблемное решение", а если не industry standard, то по крайней мере широко продвигаемые и в обычных Dev / DevOps циклах, позволяющие сохранить массу времени на failed pipelines (как часто пишут код в веб-интерфейсе?)

"Чтобы плохой код не замержился" настраивают "branch protection rules" с требованием, чтобы все проверки были зелеными (см скрин ниже).

Хотя в целом согласен, более видимый "❌ Build failed" в интерфейсе и дубликат мылом всегда полезен.

ЗЫ:

Сейчас незаметно запускается flake8, но его ошибки игнорируются.

Сейчас так настроено, что flake8 в принципе игнорируется по большиству базы:

          # stop the build if there are Python syntax errors or undefined names
          flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics
          # exit-zero treats all errors as warnings.
          flake8 . --count --exit-zero --statistics

[igoose1]

Ни pre-commit хук, ни protected branch не решают это issue. Этот issue про то, что ревьюеры пропускают плохой код и не знают об этом. pre-commit не поможет, пока он не запускается в pipeline; protected branch не поможет, пока в pipelines нет ничего полезного. Возможно, ты пытаешься решить какую-то другую проблему. Для нее можно создать отдельный issue.

[sfuerte]

pre-commit хуки это предложение по оптимизации и ускорению процессов, чтобы не ждать и не отвлекаться на linting/formatting и failed pipelines.
protected branch опять же автоматизация "чтобы плохой код не замержился".

Ну а если вопрос только в

Сделайте так, чтобы перед ревью автору приходили "❌ Build failed" и ответственность за хороший код была на нем.

то к админу репы это никакого отношение не имеет, as per https://docs.github.com/en/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications, это настройки самого дева:

For repositories that are set up with GitHub Actions and that you are watching

Для всех "watching" реп, емайл должен приходить. Если нет - то больше вопрос к саппорту Гитхаба.