Вклад в базу кода Calico

Спасибо за желание внести свой вклад в проект Calico! Данное руководство описывает канонический процесс внесения новых функциональностей и исправлений ошибок в кодовой базе Calico. Соблюдение этих шагов поможет быстро и эффективно включить ваш вклад.

Обзор

Это новая функциональность?

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

Помните, что согласование дизайна заранее значительно увеличит шансы принятия вашего запроса на слияние и минимизирует время, необходимое как вам, так и вашему рецензенту!

Это простое исправление ошибки?

Простые исправления ошибок могут быть представлены в виде запроса на слияние. Убедитесь, что вы описали ошибку в описании запроса на слияние, и попробуйте воспроизвести ошибку в юнит тестах. Это поможет гарантировать, что ошибка останется исправленной!

Написание, тестирование и сборка кода

Для более подробной информации о процедуре разработки для Calico, см. руководство для разработчиков.

Процесс запроса на слияние

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

1. Создайте личную форк репозитория.
2. Получите последний код из ветки master и создайте ветку функциональности на основе этой ветки в вашем форке.
3. Реализуйте свою функциональность. Коммиты в Git дешёвы; попробуйте разделить ваш код на множество небольших частей. Это также делает проверку легче и позволяет более логично объединять изменения.
4. Убедитесь, что существующие тесты проходят успешно, и что вы написали новые тесты для любой новой функциональности. Каждый каталог имеет свой набор тестов.
5. Отправьте вашу ветку функциональности в ваш форк на GitHub.
6. Создайте запрос на слияние через GitHub, от вашего форка и ветки до проекта Calico master.
   1. Если вы ещё этого не сделали, вам потребуется согласиться с нашим соглашением о взаимодействии. Смотрите ниже.
   2. Открытие запроса на слияние автоматически запустит ваши изменения через нашу систему CI. Убедитесь, что все предварительные тесты прошли успешно, чтобы поддерживатель мог слить ваш вклад.
7. Ждите проверки со стороны поддерживателя.
8. Когда вы получили обратную связь:
   1. Обратите внимание на замечания рецензента в своей ветке функциональности.
   2. Отправьте изменения в ваш форк на GitHub в новом коммите — не объединяйте! Это автоматически обновляет запрос на слияние.
   3. Если необходимо, сделайте верхнеуровневый комментарий типа «Пожалуйста, повторно проверьте», уведомив своего рецензента, и повторите вышеописанные шаги.
   4. Как только все требуемые изменения будут выполнены, ваш рецензент может попросить вас объединить ваши коммиты. Если да, объедините коммиты в один с одним описательным сообщением.
   5. Как только ваш запрос на слияние будет одобрен и коммиты будут объединены, ваш рецензент сложит запрос на слияние. Если у вас есть необходимые права доступа, вы можете слить запрос на слияние самостоятельно.

Корректировка старого выпуска

Если ваш вклад предназначен для старого выпуска, изменение должно быть перенесено в соответствующую ветку выпуска после того, как оно было проверено и слито в мастер. Чтобы убедиться, что это произойдет, примените метку cherry-pick-candidate к запросу на слияние или попросите своего рецензента сделать это.

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

1. Выберите ветку выпуска, соответствующую вашему целевому выпуску, например: git fetch upstream; git checkout release-v2.5.
2. Создайте ветку корректировки на основе целевой ветки, например: git checkout -b cherry-pick-pr12345-v2.5 release-v2.5
3. Примените корректировку к вашей новой ветке: git cherry-pick [ORIGINAL_COMMIT_HASH]
4. Отправьте ветку в ваш форк и создайте запрос на слияние против соответствующей ветки release-vX.Y.
   • Назовите запрос на слияние [release-vX.Y] cherry-pick: ORIGINAL_TITLE
   • В описании предоставьте ссылку на оригинальный запрос, чтобы его можно было легко проследить.
   • Убедитесь, что запрос на слияние находится в правильном майлстоуне GitHub для следующего выпуска vX.Y.Z.
   • Убедитесь, что вы написали заметку о выпуске и применили метку release-note-required к запросу на слияние.
5. Уведомите вашего оригинального рецензента на запросе на слияние.
6. Как только ваш запрос на слияние будет слит, удалите метку cherry-pick-candidate с оригинального запроса на слияние и замените её меткой cherry-pick-completed.

Заметки о выпусках и документация

Большинство запросов на слияние требуют заметок о выпусках — любых исправлений ошибок или новых функциональностей, которые могут быть интересны пользователям. Если вы не уверены, требуется ли заметка о выпуске в описании вашего запроса на слияние, спросите своего рецензента.

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

Каждый запрос на слияние должен иметь одну метку docs-*.- docs-pr-required: Это изменение требует доработки документации, которая ещё не завершена.

• docs-completed: Это изменение имеет всю необходимую документацию завершённой.
• docs-not-required: Это изменение не влияет на пользователя и не требует документов.

Каждый запрос на слияние должен иметь одну метку release-note-*.

• release-note-required: Этот запрос на слияние имеет изменения, влияющие на пользователя. Большинство запросов на слияние должны иметь эту метку.
• release-note-not-required: Этот запрос на слияние не имеет изменений, влияющих на пользователя.

Другие опциональные метки:

• cherry-pick-candidate: Этот запрос на слияние следует перенести в более ранний выпуск. Только для исправлений ошибок.
• needs-operator-pr: Этот запрос на слияние связан с установкой и требует соответствующих изменений оператора.

Соглашение о лицензии

Мы нуждаемся в том, чтобы вы подписали наше Соглашение о Лицензии для Вкладчиков перед тем, как мы сможем принять ваш вклад. Вас попросят это сделать как часть процесса запроса на слияние на GitHub.