Generowanie materiałów źródłowych dla polecenia kubectl
Ta strona pokazuje, jak wygenerować materiały źródłowe polecenia kubectl
.
Informacja:
Ten temat pokazuje, jak wygenerować materiały źródłowe dla poleceń kubectl takich jak kubectl apply i kubectl taint. Ten temat nie pokazuje, jak wygenerować stronę materiałów źródłowych opcji kubectl. Aby uzyskać instrukcje dotyczące generowania strony materiałów źródłowych opcji kubectl, zobacz Generowanie stron materiałów źródłowych dla komponentów i narzędzi Kubernetesa.Zanim zaczniesz
Wymagania:
-
Potrzebujesz maszyny z systemem operacyjnym Linux lub macOS.
-
Musisz mieć zainstalowane następujące narzędzia:
-
Twoja zmienna środowiskowa
PATH
musi zawierać wymagane narzędzia do budowania, takie jak binariaGo
ipython
. -
Musisz wiedzieć, jak utworzyć pull requesta do repozytorium na GitHubie. Wymaga to utworzenia własnego forka repozytorium. Aby uzyskać więcej informacji, zobacz Praca z lokalnej kopii.
Skonfiguruj lokalne repozytoria
Utwórz lokalną przestrzeń roboczą i ustaw swoje GOPATH
:
mkdir -p $HOME/<workspace>
export GOPATH=$HOME/<workspace>
Utwórz lokalną kopię następujących repozytoriów:
go get -u github.com/spf13/pflag
go get -u github.com/spf13/cobra
go get -u gopkg.in/yaml.v2
go get -u github.com/kubernetes-sigs/reference-docs
Jeśli nie masz jeszcze repozytorium kubernetes/website, pobierz je teraz:
git clone https://github.com/<your-username>/website $GOPATH/src/github.com/<your-username>/website
Zrób klon repozytorium kubernetes/kubernetes jako k8s.io/kubernetes:
git clone https://github.com/kubernetes/kubernetes $GOPATH/src/k8s.io/kubernetes
Usuń pakiet spf13 z $GOPATH/src/k8s.io/kubernetes/vendor/github.com
:
rm -rf $GOPATH/src/k8s.io/kubernetes/vendor/github.com/spf13
Repozytorium kubernetes/kubernetes dostarcza kod źródłowy kubectl
oraz kustomize
.
-
Określ katalog bazowy twojej kopii repozytorium kubernetes/kubernetes. Na przykład, jeśli postępowałeś zgodnie z poprzednim krokiem, aby pobrać repozytorium, twój katalog bazowy to
$GOPATH/src/k8s.io/kubernetes
. Kolejne kroki odwołują się do twojego katalogu bazowego jako<k8s-base>
. -
Określ katalog bazowy klonu Twojego repozytorium kubernetes/website. Na przykład, jeśli wykonałeś poprzedni krok, aby pobrać repozytorium, Twoim katalogiem bazowym jest
$GOPATH/src/github.com/<your-username>/website
. Kolejne kroki odnoszą się do Twojego katalogu bazowego jako<web-base>
. -
Określ katalog główny dla Twojej kopii repozytorium kubernetes-sigs/reference-docs. Na przykład, jeśli postępowałeś zgodnie z poprzednim krokiem, aby uzyskać repozytorium, Twoim katalogiem głównym będzie
$GOPATH/src/github.com/kubernetes-sigs/reference-docs
. Dalsze kroki odnoszą się do Twojego katalogu głównego jako<rdocs-base>
.
W swoim lokalnym repozytorium k8s.io/kubernetes przejdź do interesującej Cię gałęzi i upewnij się, że jest ona aktualna. Na przykład, jeśli chcesz wygenerować dokumentację dla Kubernetesa 1.31.0, możesz użyć tych poleceń:
cd <k8s-base>
git checkout v1.31.0
git pull https://github.com/kubernetes/kubernetes 1.31.0
Jeśli nie musisz edytować kodu źródłowego kubectl
, postępuj zgodnie z
instrukcjami dotyczącymi Ustawiania zmiennych kompilacji.
Edytowanie kodu źródłowego kubectl
Materiały źródłowe polecenia kubectl są automatycznie generowana z kodu źródłowego kubectl. Jeśli chcesz zmienić materiały źródłowe, pierwszym krokiem jest zmiana jednego lub więcej komentarzy w kodzie źródłowym kubectl. Wprowadź zmianę w swoim lokalnym repozytorium kubernetes/kubernetes, a następnie zgłoś pull requesta do gałęzi master na github.com/kubernetes/kubernetes.
PR 56673 jest przykładem pull requesta, który poprawia literówkę w kodzie źródłowym kubectl.
Monitoruj swój pull request (PR) i odpowiadaj na komentarze recenzentów. Kontynuuj monitorowanie swojego PR, aż zostanie scalony z docelową gałęzią w repozytorium kubernetes/kubernetes.
Zrób cherry pick do gałęzi wydania
Twoja zmiana znajduje się teraz w głównej gałęzi, która jest używana do rozwoju następnego wydania Kubernetesa. Jeśli chcesz, aby twoja zmiana pojawiła się w wersji dokumentacji Kubernetesa, która została już wydana, musisz zaproponować włączenie twojej zmiany do gałęzi wydania.
Na przykład, załóżmy, że gałąź master jest używana do rozwijania Kubernetes 1.32 i chcesz przenieść swoją zmianę do gałęzi release-1.31. Aby uzyskać instrukcje, jak to zrobić, zobacz Proponowanie Cherry Pick.
Monitoruj swój cherry pick pull request, aż zostanie scalone z gałęzią wydania.
Informacja:
Proponowanie cherry pick wymaga posiadania uprawnień do ustawiania etykiety oraz kamienia milowego w swoim pull requeście. Jeśli nie posiadasz tych uprawnień, będziesz musiał współpracować z kimś, kto może ustawić etykietę i kamień milowy za Ciebie.Ustaw zmienne budowania
Przejdź do <rdocs-base>
. W swoim wierszu poleceń ustaw następujące zmienne środowiskowe.
- Ustaw
K8S_ROOT
na<k8s-base>
. - Ustaw
K8S_WEBROOT
na<web-base>
. - Ustaw
K8S_RELEASE
na wersję dokumentacji, którą chcesz zbudować. Na przykład, jeśli chcesz zbudować dokumentację dla Kubernetesa 1.31, ustawK8S_RELEASE
na 1.31.
Na przykład:
export K8S_WEBROOT=$GOPATH/src/github.com/<your-username>/website
export K8S_ROOT=$GOPATH/src/k8s.io/kubernetes
export K8S_RELEASE=1.31
Tworzenie katalogu wersjonowanego
Uruchomienie budowania (ang. build target) createversiondirs
tworzy katalog z
wersjonowaniem i kopiuje pliki konfiguracyjne kubectl dotyczące materiałów źródłowych do tego
katalogu. Nazwa katalogu z wersjonowaniem jest zgodna z wzorcem v<major>_<minor>
.
W katalogu <rdocs-base>
, uruchom następujący cel budowania:
cd <rdocs-base>
make createversiondirs
Sprawdź tag wydania w k8s.io/kubernetes
W swoim lokalnym repozytorium <k8s-base>
, przejdź do gałęzi, która zawiera
wersję Kubernetesa, którą chcesz udokumentować. Na przykład, jeśli chcesz
wygenerować dokumentację dla Kubernetesa 1.31.0, przejdź do tagu v1.31
.
Upewnij się, że Twoja lokalna gałąź jest aktualna.
cd <k8s-base>
git checkout v1.31.0
git pull https://github.com/kubernetes/kubernetes v1.31.0
Uruchom kod generowania dokumentacji
W lokalnym katalogu <rdocs-base>
, uruchom cel budowania (ang. build target) copycli
. Komenda działa z uprawnieniami root
:
cd <rdocs-base>
make copycli
Polecenie copycli
czyści tymczasowy katalog kompilacji, generuje pliki poleceń kubectl i
kopiuje zbiorczą stronę HTML materiałów źródłowych poleceń kubectl oraz zasoby do <web-base>
.
Zlokalizuj wygenerowane pliki
Zweryfikuj, czy te dwa pliki zostały wygenerowane:
[ -e "<rdocs-base>/gen-kubectldocs/generators/build/index.html" ] && echo "index.html built" || echo "no index.html"
[ -e "<rdocs-base>/gen-kubectldocs/generators/build/navData.js" ] && echo "navData.js built" || echo "no navData.js"
Zlokalizuj skopiowane pliki
Zweryfikuj, czy wszystkie wygenerowane pliki zostały skopiowane do Twojego <web-base>
:
cd <web-base>
git status
Wynik powinien zawierać zmodyfikowane pliki:
static/docs/reference/generated/kubectl/kubectl-commands.html
static/docs/reference/generated/kubectl/navData.js
Wynik może również zawierać:
static/docs/reference/generated/kubectl/scroll.js
static/docs/reference/generated/kubectl/stylesheet.css
static/docs/reference/generated/kubectl/tabvisibility.js
static/docs/reference/generated/kubectl/node_modules/bootstrap/dist/css/bootstrap.min.css
static/docs/reference/generated/kubectl/node_modules/highlight.js/styles/default.css
static/docs/reference/generated/kubectl/node_modules/jquery.scrollto/jquery.scrollTo.min.js
static/docs/reference/generated/kubectl/node_modules/jquery/dist/jquery.min.js
static/docs/reference/generated/kubectl/node_modules/font-awesome/css/font-awesome.min.css
Lokalne testowanie dokumentacji
Zbuduj dokumentację Kubernetes w lokalnym <web-base>
.
cd <web-base>
git submodule update --init --recursive --depth 1 # if not already done
make container-serve
Zobacz podgląd lokalny.
Dodaj i zatwierdź zmiany w kubernetes/website
Uruchom git add
i git commit
, aby zatwierdzić pliki.
Utwórz pull requesta
Utwórz pull requesta do repozytorium kubernetes/website
.
Monitoruj swój pull request i odpowiadaj na komentarze z przeglądu.
Kontynuuj monitorowanie swojego pull requesta aż do momentu jego włączenia do głównej gałęzi kodu.
Kilka minut po włączeniu twojego pull requesta, zaktualizowane tematy materiałów źródłowych będą widoczne w opublikowanej dokumentacji.