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

OSCHINA-MIRROR/mirrors-KSQL

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Клонировать/Скачать
CONTRIBUTING.md 25 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
gitlife-traslator Отправлено 28.11.2024 07:33 e6dfb69

Участие

Спасибо за помощь в улучшении ksqlDB!

Если у вас есть вопросы о том, как внести свой вклад, создайте проблему на GH или задайте свой вопрос в канале #ksqldb нашего общедоступного сообщества Confluent Slack (регистрация учётной записи бесплатна и выполняется самостоятельно).

Разработка ksqlDB

Об Apache Maven wrapper

Версии разработки ksqlDB используют диапазоны версий для зависимостей от других проектов Confluent, и из-за ошибки в Apache Maven вы можете обнаружить, что и Maven, и ваша IDE загружают сотни или тысячи файлов pom при разрешении зависимостей. Они кэшируются, поэтому это будет наиболее заметно при свежих форках или переключении на ветки, которые вы давно не использовали.

Пока мы не сможем получить исправление и официально выпустить его, нам нужно обойти ошибку. Мы добавили скрипт-обёртку Maven и настроили его для загрузки исправленной версии Maven. Вы можете использовать эту обёртку, просто заменив ./mvnw вместо mvn для каждого вызова Maven. Патч экспериментальный, так что если он вызовет у вас какие-то проблемы, вы можете вернуться к официальному релизу, просто снова используя mvn. Пожалуйста, сообщите нам, если у вас возникнут проблемы с обёрткой.

Вы также можете настроить IntelliJ IDEA для использования исправленной версии Maven. Сначала получите путь к исправленному домашнему каталогу Maven:

$ ./mvnw -v
...
Maven home: /home/john/.m2/wrapper/dists/apache-maven-3.8.1.2-bin/1npbma9t0n1k5b22fpopvupbmn/apache-maven-3.8.1.2
...

Затем обновите домашний каталог Maven в Settings > Build, Execution, Deployment > Build Tools > Maven и установите значение Maven home path в тот же каталог, указанный как «домашний каталог Maven» выше. В приведённом выше примере это /home/john/.m2/wrapper/dists/apache-maven-3.8.1.2-bin/1npbma9t0n1k5b22fpopvupbmn/apache-maven-3.8.1.2, но на вашем компьютере он может быть другим.

Наконец, вам может потребоваться перезапустить IDE, чтобы она перезагрузила двоичный файл Maven.

Вероятно, для других IDE доступна аналогичная опция.

Сборка и запуск ksqlDB локально

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

$ ./mvnw clean package -DskipTests
$ ./bin/ksql-server-start -daemon config/ksql-server.properties
$ ./bin/ksql

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

Если вы предпочитаете, чтобы журналы сервера ksqlDB выводились на консоль, то запустите CLI во второй консоли без переключателя -daemon.

Рекомендуется настроить maven для использования собственного клиента git в вашей системе, установив export MAVEN_OPTS="-Dmaven.gitcommitid.nativegit=true $MAVEN_OPTS". Это значительно сократит время сборки.

Сборка выпущенной версии

Исходный код автономных версий ksqlDB помечен шаблоном vN.NN.N. Например, тег для автономного выпуска 0.28.2 — v0.28.2.

Если вы хотите собрать выпущенную версию, выполните следующие команды, заменив 0.28.2 желаемой версией:

$ git fetch origin --tags
$ git checkout v0.28.2
$ ./mvnw --settings maven-settings.xml clean package -DskipTests

Обратите внимание, что аргумент --settings maven-settings.xml необходим для обеспечения возможности извлечения всех зависимостей относительно целевой версии.

Запуск в IDE

Вам следует настроить свою IDE для использования обёртки Maven (см. «Об Apache Maven wrapper» выше).

Вы можете создать конфигурацию запуска в своей среде IDE для основного класса: io.confluent.ksql.rest.server.KsqlServerMain, используя путь к классам модуля ksqldb-rest-app и указав путь к файлу конфигурации в качестве аргумента программы. Существует базовый файл конфигурации, доступный в config/ksql-server.properties.

ПРИМЕЧАНИЕ: По крайней мере, для IDEA (и, возможно, для других сред IDE) сборка проекта автоматически не запускает фазу Maven generate-sources, поэтому наши классы ANTLR и Avro будут отсутствовать (если только вы случайно не собрали с помощью Maven). ### Как это работает

В последнее время. Вы можете сгенерировать их, выполнив:

$ ./mvnw --projects ksqldb-parser,ksqldb-version-metrics-client generate-sources

Если вы хотите использовать CLI со своим сервером, вы можете либо заранее собрать его с помощью команды package выше, либо скомпилировать и запустить класс из терминала с помощью maven:

$ ./mvnw compile exec:java --projects ksqldb-cli -Dexec.mainClass="io.confluent.ksql.Ksql"

Тестирование изменений локально

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

$ ./mvnw verify -T 1.5C

Этот пример демонстрирует новую функцию параллельной сборки Maven 3. Если она вызывает у вас проблемы, вы можете изменить аргумент параллелизма или вообще отказаться от опции -T ....

Тестирование образа Docker

Инструкции по сборке и запуску образов Docker см. в комментариях в верхней части файла docker compose в корне проекта.

Как внести свой вклад

Сообщение об ошибках и проблемах

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

Рекомендации по внесению кода, примеров, документации

Любое изменение общедоступного API ksqlDB, особенно синтаксиса SQL, требует создания и утверждения предложения по улучшению KsqlDB (KLIP). Подробнее см. в README KLIP.

Изменения кода отправляются через запрос на вытягивание (PR). При отправке PR используйте следующие рекомендации:

  • Следуйте приведённому ниже руководству по стилю.
  • Добавьте или обновите документацию в соответствии с изменениями, которые вы вносите. Для получения дополнительной информации см. README документации.
  • Непростые изменения должны включать модульные тесты, охватывающие новую функциональность, и потенциально функциональные тесты.
  • Все изменения и улучшения синтаксиса SQL должны сопровождаться соответствующими функциональными тестами.
  • Исправления ошибок должны включать модульный тест или интеграционный тест, потенциально функциональный тест, доказывающий, что проблема устранена.
  • Старайтесь делать запросы на вытягивание короткими и отправлять отдельные запросы для несвязанных функций.
  • Храните изменения форматирования в отдельных коммитах, чтобы упростить проверку кода и отличить их от реальных изменений кода.

Руководство по стилю

Проект использует форматирование кода GoogleStyle. Вы можете установить этот стиль кода в свою IDE, чтобы сделать процесс более автоматическим:

В проекте также используются неизменяемые типы везде, где это возможно. Если вы добавляете новые типы, в идеале сделайте их неизменяемыми.

Статический анализ кода

Сборка проекта запускает checkstyle и findbugs как часть сборки.

Вы можете настроить IntelliJ для CheckStyle. Сначала установите плагин CheckStyle IDEA, затем:

IntelliJ → Настройки → Инструменты → CheckStyle

В левом верхнем углу выберите CheckStyle версии 8.44 или новее (более старые версии не могут проанализировать предоставленный XML)

- Добавьте новый файл конфигурации с помощью кнопки «+»:
   Описание: Confluent Checks
   URL: https://raw.githubusercontent.com/confluentinc/common/master/build-tools/src/main/resources/checkstyle/checkstyle.xml
   Ignore invalid certs: true

- (Необязательно) Сделайте новую конфигурацию активной.

- Выделите только что добавленные «Confluent Checks» и нажмите кнопку редактирования (значок карандаша).

- Установите свойства в соответствии с файлом `checkstyle/checkstyle.properties` в репозитории.

Теперь «Confluent Checks» будет доступен в окне инструментов CheckStyle в среде IDE и автоматически выделит проблемы в редакторе кода. Обычные коммиты

[Обычные коммиты][1] для сообщений коммитов, чтобы упростить автоматическое создание журналов изменений. Как описано в спецификации обычных коммитов (Conventional Commits), сообщения коммитов должны быть в следующем формате:

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

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

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

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

  • «fix»: для исправлений ошибок;
  • «feat»: для новых функций;
  • «perf»: для улучшений производительности;
  • «revert»: для отмены других изменений.

Типы коммитов, которые не отображаются в журналах изменений, включают:

  • «docs»: только для изменений документации;
  • «test»: только для тестовых изменений;
  • «refactor»: для рефакторинга;
  • «style»: только стилистические изменения;
  • «build»: для связанных со сборкой изменений;
  • «chore»: для автоматических изменений, а также других изменений, не имеющих отношения к пользователям. Сюда могут входить изменения, которые не вписываются ни в одну из вышеперечисленных категорий, например PR, содержащие прогресс в отношении незавершённой функции.

(Необязательная) область — это существительное, описывающее раздел кодовой базы, на который влияет изменение. Примеры, которые могут иметь смысл для ksqlDB, включают «парсер», «анализатор», «сервер отдыха», «инструмент тестирования», «cli», «обработка журнала» и «метрики».

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

Критические изменения

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

  • Сообщения коммитов для критических изменений должны включать строку (в дополнительном теле или нижнем колонтитуле), начинающуюся с «BREAKING CHANGE:», за которой следует объяснение критического изменения. Например:

    feat: inherit num partitions and replicas from source topic in CSAS/CTAS
    
    BREAKING CHANGE: `CREATE * AS SELECT` запросы теперь создают темы приёмника с разделами
    и количеством реплик, равными таковым у исходной темы, вместо использования значений из свойств
    `ksql.sink.partitions` и `ksql.sink.replicas`. Эти свойства теперь устарели.
  • Критическое изменение также должно быть указано в описании PR. Это описание будет скопировано в тело окончательного коммита, объединённого с репо, и соответствующим образом учтено нашей автоматической генерацией журнала изменений.

  • Примечания по обновлению [2] также должны быть обновлены в рамках того же PR.

Commitlint

В этом проекте настроен commitlint [3], чтобы гарантировать, что сообщения коммитов имеют ожидаемый формат. Чтобы включить commitlint, просто запустите npm install из корневого каталога репозитория ksqlDB (после [установки npm][4]). После включения commitlint будет отклонять коммиты с неправильно отформатированными сообщениями коммитов.

GitHub Workflow

  1. Создайте форк репозитория confluentinc/ksql на своём аккаунте GitHub: https://github.com/confluentinc/ksql/fork.

  2. Клонируйте свой форк репозитория GitHub, заменив <username> своим именем пользователя GitHub.

    Используйте ssh (рекомендуется):

    git clone git@github.com:<username>/ksql.git

    Или https:

    git clone https://github.com/<username>/ksql.git
  3. Добавьте удалённый сервер, чтобы следить за изменениями upstream.

    git remote add upstream https://github.com/confluentinc/ksql.git

    Если у вас уже есть копия, получите изменения upstream.

    git fetch upstream
  4. Создайте ветку функций для работы.

    git checkout -b feature-xxx
    

[1] Conventional Commits — https://www.conventionalcommits.org/en/v1.0.0-beta.4/ [2] Upgrade notes — https://github.com/confluentinc/ksql/blob/master/docs/installation/upgrading.rst [3] Commitlint — https://github.com/conventional-changelog/commitlint [4] Установка npm — https://www.npmjs.com/get-npm Удалённые / восходящий поток / мастер

5. Работайте в своей функциональной ветке.

   ```bash
   git commit -a
  1. Периодически перебазируйте свои изменения

    git pull --rebase
  2. Когда закончите, объедините («сквош») связанные коммиты в один

    git rebase -i upstream/master

    Откроется редактор, который позволит вам изменить порядок коммитов и объединить их:

    • Измените порядок строк, чтобы изменить порядок коммитов (насколько это возможно без создания конфликтов)
    • Используйте префикс s (сквош) или f (фикcап), чтобы объединить лишние коммиты.
  3. Отправьте запрос на вытягивание

    git push origin feature-xxx

    Перейдите на главную страницу вашего форка

    https://github.com/<username>/ksql

    Если вы недавно отправили свои изменения, GitHub автоматически предложит кнопку «Сравнить и запросить вытягивание» для любых веток, которые вы недавно отправили. Если вы нажмёте эту кнопку, она автоматически предложит вам отправить запрос на вытягивание в репозиторий confluentinc/ksql.

    • Дайте своему запросу на вытягивание содержательный заголовок, соответствующий спецификации Conventional Commits, как описано выше для сообщений о коммите. Вы узнаете, что ваш заголовок правильно отформатирован, когда проверка Semantic Pull Request на GitHub перейдёт из состояния «ожидает» в состояние «пройдена».
    • В описании объясните свои изменения и проблему, которую они решают. Обязательно также укажите любые критические изменения, как описано выше.
  4. Ответ на комментарии к коду проверки

    Повторите шаги с 5 по 7, чтобы ответить на комментарии к проверке кода и при необходимости перебазировать свои изменения.

    Отправьте обновлённые изменения, чтобы обновить запрос на вытягивание.

    git push origin [--force] feature-xxx

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

    Примечание: Будьте осторожны при использовании --force, так как вы можете потерять данные, если не будете осторожны.

    git push origin --force feature-xxx

Перенос коммитов

Могут возникнуть ситуации, когда определённый коммит необходимо перенести в предыдущий выпуск ksqlDB (либо в редакцию сообщества, либо в редакцию confluent). В таких ситуациях выбирайте отдельные коммиты для предыдущих веток (не объединяйте несколько коммитов в один и не переносите их, потому что наш инструмент генерации журнала изменений неправильно обрабатывает объединённые коммиты).

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

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

1
https://api.gitlife.ru/oschina-mirror/mirrors-KSQL.git
git@api.gitlife.ru:oschina-mirror/mirrors-KSQL.git
oschina-mirror
mirrors-KSQL
mirrors-KSQL
master