Requested improvements for CI/CD and docs.

[nicl-nno]

[ ] "I would suggest to also test the code style in CI and maybe even apply an automated code formatter such as black." [ ] "The tool comes with an extensive documentation, but there are a bunch of things that should be improved: Community Standards should be improved. Github has a checklist that should be taken into account."

[DRMPN]

Code style

https://black.readthedocs.io/en/stable/integrations/github_actions.html

Further, the black badge can be added to the readme: https://black.readthedocs.io/en/stable/index.html#show-your-style

Community Standards

https://opensource.guide/ https://github.com/aimclub/FEDOT/community

• [x] Code of conduct
• [x] Contributing
• [x] Security policy
• [x] Issue templates
• [x] Pull request template
• [x] Repository admins accept content reports

[DRMPN]

Я бы предложил обсудить выбор форматтера для этого проекта с другими коллегами и прийти к консенсусу.

Возможные варианты:

• autopep8
• black
• yapf
• и другие

Я для своих задач использую isort + black. Первый для сортировки импортов, второй для форматирования кода. Пример работы black:

• Запуск на всю директорию, github не сравился с большим обьемом текста т.к. нужно все файлы форматировать https://github.com/aimclub/FEDOT/pull/1195/checks
• Запуск на директорию "./fedot/utilities", можно посмотреть пример форматирования https://github.com/DRMPN/FEDOT/actions/runs/6847937761/job/18617142324?pr=1

[nicl-nno]

Я бы в целом выбрал тот из них, который хорошо конфигурируется и позволяет править только грубые ошибки - чтобы не переворашиваться весь код сейчас. Мб autopep8.

[DRMPN]

Привет, работаю над автоматическим исправлением кода под PEP8, есть такие варианты: 1) При открытии ПР с ошибками в PEP8 бот будет:

• ставить check в статус failed
• создать отдельный ПР с исправлением,
• создавать в исходном ПР комментарий, с ссылкой на исправленный ПР
• в отдельном ПР бот будет тэгать человека из исходного ПР и просить его сделать merge
• ДОПОЛНИТЕЛЬНО (можно настроить автоматический merge в репозитории, чтобы не ждать подтверждения)
• после успешного merge ставить check в статус success Пример работы - https://github.com/DRMPN/FEDOT/pull/2 Считаю его +- нормальным вариантом, только еще доработать нужно и проверить работу 2) При открытии ПР любой человек самостоятельно в комментарии пишет команду "/autopep8":
• бот инициирует проверку
• сам делает коммит с исправлениями
• ставит реакцию на команду при успешном выполнении Тоже хороший вариант, однако тут уже нужно самим эту команду прописывать 3) Вариант с direct push, однако тут есть какие-то проблемы, т.к. нужен персональный токен и ПР должен быть не от форка Пока не пробовал, думаю проверить позже 4) Вариант с 2) только команду пишет бот, а не только человек

[nicl-nno]

Наверное, идеальным была бы вариация варианта 1, в котором бот делает проверку каждый раз, но PR создает только по требованию (чтобы не спамить).

[DRMPN]

Рабочий PR - https://github.com/DRMPN/FEDOT/pull/5 Сделал 1/2 логику работы action, осталось сделать команду для создания PR с изменениями. Нужно ли использовать реакции для автоматических комментариев при проверке т.к. есть возможность их настроить?

• Текст комментария при первой проверке (уже обновил текст, выглядит как на следующей картинке):

• Текст комментария обновляется при следующих проверках:

[nicl-nno]

Нужно ли использовать реакции для автоматических комментариев при проверке т.к. есть возможность их настроить?

А реакции триггерят какие-то действия или в чем их роль?

[DRMPN]

А реакции триггерят какие-то действия или в чем их роль?

Роли никакой не играют, просто для красоты тд тп

[DRMPN]

Наверное, идеальным была бы вариация варианта 1, в котором бот делает проверку каждый раз, но PR создает только по требованию (чтобы не спамить).

Реализовал такой вариант, примеры: https://github.com/DRMPN/FEDOT/pull/5 и https://github.com/DRMPN/FEDOT/pull/10

• Проверяет каждый раз, создает один комментарий, а после только обновляет его.
• Создает ПР с изменениями только по требованию.
• Если запросить команду несколько раз подряд, то будет изменять уже созданный ПР.
• Для каждой ветки создает отдельный ПР с изменениями, так что несколько ПР не пересекаются.

Есть возможность пропустить шаг создания отдельного ПР с изменениями и по команде сразу делать коммит в текущий ПР, как лучше сделать?

P.S. Есть куча настроек, если что-то не нравится в описании, команде, тексте, слове и т.д., то могу изменить по требованию.

[DRMPN]

• Code of conduct правила для общения и поведения можно взять отсюда и выбрать их версию, они достаточно легки и гибки, если сравнивать с другими: например [1] или [2].

• Repository admins accept content reports нужно включить для контроля за соблюдением правил из code of conduct. Можно найти в настройках, там же с ними и работать:

• Security policy не думаю, что в проекте это необходимо т.к. опасности извне быть не должно.

[DRMPN]

Создал следующие документы:

• Contributing - https://github.com/DRMPN/FEDOT/pull/13
• Issue templates - https://github.com/DRMPN/FEDOT/pull/12
• Pull request template - https://github.com/DRMPN/FEDOT/pull/14

Посмотрите, наверняка их нужно как-нибудь отредактировать.

[nicl-nno]

Посмотрите, наверняка их нужно как-нибудь отредактировать.

Оставил пару комментариев, но в целом как будто то что нужно.