1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/iot-kubeedge-kubeedge-kubeedge

Клонировать/Скачать
CONTRIBUTING.md 14 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
gitlife-traslator Отправлено 30.11.2024 19:43 aadb481

Добро пожаловать!

Добро пожаловать в KubeEdge!

Прежде чем начать

Кодекс поведения

Пожалуйста, ознакомьтесь и соблюдайте наш Кодекс поведения.

Ожидания сообщества

KubeEdge — это проект сообщества, который продвигается его участниками и стремится создать здоровую, дружелюбную и продуктивную среду. Цель сообщества — разработать облачную платформу для граничных вычислений на основе Kubernetes для управления граничными узлами и устройствами в масштабе и продемонстрировать устойчивость и надёжность в автономных сценариях. Чтобы построить платформу такого масштаба, требуется поддержка сообщества с аналогичными стремлениями.

— См. Членство в сообществе для получения списка различных ролей в сообществе. Постепенно внося свой вклад, можно продвигаться вверх по цепочке.

Начало работы

— Создайте форк репозитория на GitHub. — Ознакомьтесь с инструкциями по настройке для развёртывания.

Ваш первый вклад

Мы поможем вам внести свой вклад в различные области, такие как создание задач, разработка функций, исправление критических ошибок и получение отзывов о вашей работе и её объединение.

Если у вас есть вопросы о процессе разработки, не стесняйтесь присоединиться к нашему каналу Slack или подписаться на нашу рассылку.

Найдите, над чем поработать

Нам всегда нужна помощь, будь то исправление документации, сообщение об ошибках или написание кода. Посмотрите, где, по вашему мнению, необходимо улучшить качество кода, провести рефакторинг кода или добавить тесты. Вот как вы можете начать.

Выберите хорошую первую тему

В организации KubeEdge есть несколько репозиториев. Каждый репозиторий содержит задачи, которые подходят для начинающих и предоставляют хорошую первую задачу. Например, kubeedge/kubeedge имеет метки требуется помощь и хорошая первая задача, которые указывают на задачи, для выполнения которых не требуется глубоких знаний системы. Мы можем помочь новым участникам, желающим работать над такими задачами.

Ещё один хороший способ внести свой вклад — найти улучшение документации, например, отсутствующую или неработающую ссылку. Пожалуйста, см. раздел Внесение вклада ниже для ознакомления с рабочим процессом.

Работайте над задачей

Когда вы готовы взяться за задачу, вы можете назначить её себе. Просто ответьте /assign или /assign @yourself на задачу, после чего робот назначит задачу вам, и ваше имя появится в списке исполнителей.

Создайте задачу

Хотя мы призываем всех вносить код, также приветствуется, когда кто-то сообщает об ошибке. Задачи следует создавать в соответствующем подрепозитории KubeEdge.

Пример: задачу KubeEdge следует открывать в kubeedge/kubeedge.

При открытии задачи следуйте предложенным рекомендациям.

Рабочий процесс участника

Не стесняйтесь задавать вопросы или отправлять запросы на вытягивание.

Вот примерный план рабочего процесса участника:

— Создайте тематическую ветку, на основе которой будет осуществляться вклад. Обычно это основная ветка. — Делайте коммиты логических единиц. Убедитесь, что сообщения коммитов имеют правильный формат (см. ниже).

  • Внесите изменения в тематическую ветку и отправьте их в свой форк репозитория.
  • Отправьте запрос на включение изменений в kubeedge/kubeedge.
  • Запрос на включение должен быть одобрен двумя сопровождающими.

Создание запросов на включение

Запросы на включение часто называют просто «PR». KubeEdge обычно следует стандартному процессу запроса на включение GitHub. Чтобы предложить изменение, пожалуйста, разработайте код/исправьте ошибки и добавьте новые тестовые случаи. После этого выполните следующие локальные проверки перед отправкой запроса на включение, чтобы предсказать успех или неудачу непрерывной интеграции.

  • Запустите и успешно завершите make verify.
  • Запустите и успешно завершите make edge_test или make cloud_test.
  • Запустите и успешно завершите make edge_integration_test.

В дополнение к вышеуказанному процессу бот начнёт применять структурированные метки к вашему запросу на включение.

Бот также может дать несколько полезных советов по командам, которые можно запустить в вашем запросе на включение для облегчения проверки. Эти опции /command можно ввести в комментариях, чтобы активировать автоматическую маркировку и уведомления. Обратитесь к его документации по справочным командам.

Проверка кода

Чтобы вашему запросу на включение было легче получить отзывы, рассмотрите следующие рекомендации:

  • Следуйте хорошим рекомендациям по кодированию.
  • Пишите хорошие сообщения о коммите.
  • Разбивайте большие изменения на логическую серию небольших исправлений, каждое из которых вносит легко понятные изменения, а в совокупности решает более широкую проблему.
  • Помечайте запросы на включение соответствующими рецензентами: для этого прочитайте сообщения, которые отправляет вам бот, чтобы провести вас через процесс запроса на включение.

Формат сообщения о коммите

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

scripts: add test codes for metamanager

this add some unit test codes to improve code coverage for metamanager

Fixes #12

Формат можно описать более формально следующим образом:

<subsystem>: <что изменилось>
<BLANK LINE>
<почему это изменение было сделано>
<BLANK LINE>
<нижний колонтитул>

Первая строка — это тема, она должна быть не длиннее 70 символов, вторая строка всегда пустая, а остальные строки должны переноситься через 80 символов. Это позволяет сообщению легче читаться как на GitHub, так и в различных инструментах git.

Примечание: если ваш запрос на включение не получает достаточного внимания, вы можете обратиться в Slack за помощью в поиске рецензентов.

Тестирование

Существует несколько типов тестов. Расположение тестового кода зависит от типа, как и особенности среды, необходимой для успешного запуска теста:

  • Модульный: эти тесты подтверждают, что конкретная функция работает должным образом. Исходный код модульного теста можно найти рядом с соответствующим исходным кодом в данном пакете. Их легко запустить локально любому разработчику.
  • Интеграционный: эти тесты охватывают взаимодействия компонентов пакета или взаимодействия между компонентами KubeEdge и компонентами плоскости управления Kubernetes, такими как сервер API. Примером может служить проверка того, может ли контроллер устройства создавать конфигурационные карты при создании CRD устройства на сервере API.
  • Сквозное («e2e»): это обширные тесты общего поведения системы и согласованности. Тесты e2e находятся в kubeedge e2e.

Непрерывная интеграция будет запускать эти тесты на запросах на включение.

Опубликовать ( 0 )

Вы можете оставить комментарий после Вход в систему

1
https://api.gitlife.ru/oschina-mirror/iot-kubeedge-kubeedge-kubeedge.git
git@api.gitlife.ru:oschina-mirror/iot-kubeedge-kubeedge-kubeedge.git
oschina-mirror
iot-kubeedge-kubeedge-kubeedge
iot-kubeedge-kubeedge-kubeedge
master