Посібник для розробників

Цей посібник пояснює, як налаштувати ваше середовище для розробки на Helm.

Передумови

Остання версія Go
Кластер Kubernetes з kubectl (необовʼязково)
Git

Збирання Helm

Ми використовуємо Make для компіляції наших програм. Найпростіший спосіб почати:

$ make

Якщо потрібно, спочатку будуть встановлені залежності та перевірена конфігурація. Потім буде скомпільовано helm і розміщено у bin/helm.

Щоб запустити Helm локально, ви можете запустити bin/helm.

Helm відомий тим, що працює на macOS та більшості дистрибутивів Linux, включаючи Alpine.

Запуск тестів

Щоб запустити всі тести, виконайте make test. Перед цим вам потрібно мати встановлений golangci-lint.

Запуск локально

Ви можете оновити ваш шлях і додати шлях до локального виконуваного файлу Helm. В редакторі відкрийте файл конфігурації вашої оболонки. Додайте наступний рядок, замінивши <path to your binary folder> на шлях до вашої локальної теки bin.

export PATH="<path to your binary folder>:$PATH"

Це дозволить вам запускати локально створену версію Helm з вашого термінала.

Настанови щодо участі

Ми раді вашій участі. Цей проєкт має деякі настанови, щоб забезпечити (а) високу якість коду, (б) послідовність проєкту, і (в) відповідність юридичним вимогам проєктів з відкритими сирцями. Наша мета не обтяжувати учасників, а побудувати елегантний та якісний відкритий код, щоб наші користувачі отримали користь.

Переконайтеся, що ви прочитали та зрозуміли основний посібник щодо участі:

https://github.com/helm/helm/blob/main/CONTRIBUTING.md

Структура коду

Код проєкту Helm організовано наступним чином:

Самостійні програми знаходяться в cmd/. Код всередині cmd/ не призначений для повторного використання як бібліотеки.
Спільні бібліотеки зберігаються в pkg/.
Тека scripts/ містить кілька скриптів утиліт. Більшість з них використовується конвеєром CI/CD.

Управління залежностями Go змінюється, і, ймовірно, змінюватиметься протягом життєвого циклу Helm. Ми рекомендуємо розробникам не намагатися вручну управляти залежностями. Натомість ми радимо покладатися на Makefile проєкту для цього. З Helm 3 рекомендується використовувати версію Go 1.13 або новішу.

Написання документації

З Helm 3 документація була перенесена в окремий репозиторій. При написанні нових функцій, будь ласка, напишіть супутню документацію та надішліть її до репозиторію helm-www.

Єдине виключення: вивід CLI Helm (англійською) генеруються безпосередньо з бінарного файлу helm. Дивіться Оновлення довідкових документів CLI Helm для інструкцій, як згенерувати цей вивід. Після перекладу, вивід CLI не генерується і може бути знайдений у /content/<lang>/docs/helm.

Домовленості Git

Ми використовуємо Git як нашу систему контролю версій. Гілка main є домом для поточного кандидата на розробку. Релізи позначаються теґами.

Ми приймаємо зміни до коду через Pull Requests (PRs) на GitHub. Один з робочих процесів для цього виглядає наступним чином:

Форкніть репозиторій github.com/helm/helm у ваш обліковий запис GitHub
Зробіть git clone цього форку у бажану теку
Створіть нову робочу гілку (git checkout -b feat/my-feature) і працюйте з цією гілкою.
Коли ви будете готові до перегляду, залийте вашу гілку на GitHub, а потім відкрийте новий pull request у нас.

Для повідомлень комітів Git ми дотримуємося Semantic Commit Messages:

fix(helm): add --foo flag to 'helm install'

When 'helm install --foo bar' is run, this will print "foo" in the
output regardless of the outcome of the installation.

Closes #1234

Звичайні типи комітів:

fix: Виправити проблему або помилку
feat: Додати нову функцію
docs: Змінити документацію
test: Покращити тестування
ref: рефакторинг поточного коду

Звичайні області:

helm: CLI Helm
pkg/lint: Пакет lint. Дотримуйтеся аналогічної конвенції для будь-якого пакету
*: дві або більше областей

Дізнатись більше:

Deis Guidelines були натхненням для цього розділу.
Karma Runner визначає ідею семантичного повідомлення коміту.

Домовленості Go

Ми дуже уважно дотримуємося стандартів стилю кодування Go. Зазвичай запуск go fmt зробить ваш код красивим для вас.

Ми також зазвичай дотримуємося конвенцій, рекомендованих go lint і gometalinter. Запустіть make test-style, щоб перевірити відповідність стилю.

Дізнатись більше:

Effective Go представляє форматування.
Wiki Go має чудову статтю про форматування.

Якщо ви запускаєте make test, будуть виконані не тільки юніт-тести, а й тести стилю. Якщо make test не пройде, навіть з причин стилю, ваш PR не буде вважатися готовим до злиття.