Kubernetes v1.35 ta dokumentacja nie jest już aktualizowana, a wersja, którą czytasz, ma charakter archiwalny. Najnowszą dokumentację znajdziesz tutaj najnowszą wersję.
Ta sekcja zawiera informacje, które powinieneś znać przed dodaniem nowej treści.
Istnieją również dedykowane strony dotyczące pisania studiów przypadków oraz artykułów na bloga.
flowchart LR
subgraph second[Zanim zaczniesz]
direction TB
S[ ] -.-
A[Podpisz CNCF CLA] --> B[Wybierz gałąź Git]
B --> C[Jeden język na PR]
C --> F[Sprawdź
narzędzia dla współtwórców]
end
subgraph first[Podstawy współtworzenia]
direction TB
T[ ] -.-
D[Pisz dokumentację w Markdown
i buduj stronę za pomocą Hugo] --- E[Kod źródłowy w GitHub]
E --- G[Folder '/content/../docs' zawiera dokumentację
w wielu językach]
G --- H[Zapoznaj się z typami stron
i shortcode'ami w Hugo]
end
first ----> second
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
class A,B,C,D,E,F,G,H grey
class S,T spacewhite
class first,second white
Rysunek - Przygotowanie nowej treści
Powyższy rysunek przedstawia informacje, które powinieneś znać przed przesłaniem nowej treści. Szczegóły znajdują się poniżej.
/content/en/docs/. Część dokumentacji referencyjnej jest
automatycznie generowana ze skryptów w katalogu update-imported-docs/./content/. Każdy język
ma własny folder z dwuliterowym kodem określonym przez
standard ISO 639-1 . Na
przykład, źródło dokumentacji angielskiej jest przechowywane w /content/en/docs/.Wszyscy współtwórcy Kubernetesa muszą przeczytać Przewodnik dla Współtwórców i podpisać Umowę Licencyjną Współtwórcy (CLA) .
Pull requesty od autorów, którzy nie podpisali umowy CLA, nie
przechodzą testów automatycznych. Imię i adres e-mail, które podasz,
muszą zgadzać się z tymi ustawionymi w twoim git config, a twoje
imię i adres e-mail w git muszą być takie same jak te używane dla CNCF CLA.
Podczas otwierania pull requesta musisz wiedzieć z góry, na której gałęzi oprzeć swoją pracę.
| Scenariusz | Gałąź |
|---|---|
| Istniejąca lub nowa treść w języku angielskim dla bieżącego wydania | main |
| Treść dla wydania zmiany funkcji | Gałąź, która odpowiada głównej i mniejszej wersji, w której znajduje się zmiana funkcji, używając wzorca dev-<version>. Na przykład, jeśli funkcja zmienia się w wydaniu v1.37, należy dodać zmiany w dokumentacji do gałęzi dev-1.37. |
| Treść w innych językach (lokalizacje) | Użyj konwencji danej lokalizacji. Zobacz Strategia rozgałęzień lokalizacji po więcej informacji. |
Jeśli nadal nie masz pewności, którą gałąź wybrać, zapytaj na #sig-docs na Slacku.
Ogranicz żądania pull request do jednego języka na PR. Jeśli musisz wprowadzić identyczną zmianę w tym samym fragmencie kodu w wielu językach, otwórz osobne PR dla każdego języka.
Katalog narzędzi dla współtwórców dokumentacji
w repozytorium
kubernetes/website zawiera narzędzia, wspierające proces współtworzenia dokumentacji.