Посібник для розробників
Цей посібник пояснює, як налаштувати ваше середовище для розробки на 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: Fix a bug or error
- feat: Add a new feature
- docs: Change documentation
- test: Improve testing
- ref: refactor existing code
Звичайні області:
- 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 не буде вважатися готовим до злиття.
Усунення несправностей
Щоб усунути несправності та отримати допомогу від спільноти, знайдіть своє запитання у списку питань із позначкою question/support у репозиторії Helm.
Якщо ви не можете знайти тікет, який відповідає вашому запитанню, створіть новий тікет або додайте коментар до відповідного тікету, щоб поділитися своїм досвідом. Для отримання додаткової інформації про участь та пошук тікетів у репозиторії helm див. розділ Issues у Настановах щодо участі.