Сообществу Kratos нужны разработчики, поэтому перед тем как упоминать о проблеме или создавать запрос на вытягивание (pull request), прочитайте это руководство.

Сообщение об ошибке или исправление ошибок

Мы используем GitHub для управления проблемами. Если вы хотите отправить сообщение, сначала убедитесь, что вы искали существующие проблемы, запросы на вытягивание и прочитали наш FAQ.

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

Добавление новых функций

Чтобы точно определить, являются ли потребности, выдвигаемые пользователями, потребностями или разумными потребностями большинства пользователей, запрашивайте мнения сообщества в процессе предложения. Предложения, принятые сообществом, будут реализованы в виде новой функции. Для того чтобы сделать процесс предложения максимально простым, он включает три этапа: предложение, функция и PR, где предложение — это проблема, а PR — конкретная реализация функции. Чтобы сообщество могло правильно понять требования предложения, проблема с предложением должна подробно описывать функциональные требования и соответствующие ссылки или литературу. Когда большинство пользователей сообщества согласятся с этим предложением, они создадут проблему с функцией, связанную с проблемой предложения. Проблема с функцией должна подробно описывать метод реализации и демонстрацию функции в качестве ориентира для окончательной реализации функции. После того как функция будет реализована, будет инициирован запрос на объединение, чтобы связать проблему предложения и проблему функции. После завершения объединения закройте все проблемы.

Как отправить код

Если вы никогда не отправляли код на GitHub, выполните следующие действия:

1. Сначала разветвите элементы в своей учётной записи GitHub.
2. Затем создайте новую ветку функций на основе основной ветки и назовите её, например, feature-log.
3. Напишите код.
4. Отправьте код в конечную ветвь.
5. Отправьте запрос PR на GitHub.
6. Дождитесь проверки и объедините его с основной веткой.

Обратите внимание, что при отправке запроса PR вы сначала проверяете, что код соответствует правильным спецификациям кодирования и что есть полные тестовые примеры, и что информация в представлении PR лучше всего связана с соответствующей проблемой, чтобы облегчить работу аудитора.

Стандартные коммиты

<тип>[дополнительная область]: <описание>

[дополнительное тело]

[дополнительный нижний колонтитул(ы)]

Подробнее: Стандартные коммиты

тип

Существуют следующие типы коммитов:

Основной

• fix: исправление ошибки;
• feat: новая функция;
• deps: изменения внешних зависимостей;
• break: изменение, которое приводит к нарушению работы.

Другие

• docs: только изменения документации;
• refactor: изменение кода, которое не исправляет ошибку и не добавляет функцию;
• style: изменения, которые не влияют на смысл кода (пробелы, форматирование и т. д.);
• test: добавление недостающих тестов или исправление существующих тестов;
• chore: ежедневная работа, примеры и т.д.;
• ci: изменения в наших файлах конфигурации CI и сценариях.

область

Ниже приведён список поддерживаемых областей:

• транспорт;
• примеры;
• промежуточное ПО;
• конфигурация;
• команда;
• и т. д.

описание

Описание содержит краткое описание изменения:

• используйте повелительное наклонение, настоящее время: «изменение», а не «изменено» или «изменения»;
• не используйте заглавные буквы в начале;
• без точки (.) в конце.

тело

Тело должно включать мотивацию для изменения и противопоставлять его предыдущему поведению.

нижний колонтитул

Нижний колонтитул должен содержать любую информацию о нарушениях работы и также является местом для ссылки на проблемы GitHub, которые закрывает этот коммит.

примеры

Только сообщение коммита

fix: уровень отладки журнала должен быть -1  

Внимание

refactor!(transport/http): замена базовой реализации

Полное сообщение коммита

fix(log): [BREAKING-CHANGE] невозможно выполнить требование библиотеки журналов

Объясните причину, цель, реализацию

*Примечание: в тексте запроса присутствуют специальные символы, такие как квадратные скобки, фигурные скобки и другие, но в результате перевода они не были сохранены.* ## Метод и т. д.

Закрыть #777
Изменить документ doc/#111
КРИТИЧЕСКОЕ ИЗМЕНЕНИЕ:
  Нарушает работу API log.info, вместо него следует использовать log.log

Релиз

Для создания журнала изменений в процессе разработки можно использовать команду kratos changelog dev.

Список поддерживаемых типов:

• Критическое изменение
• Зависимости
• Исправления ошибок
• Прочее