kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
community/contributors/guide/contributor-cheatsheet/README-de.md

16 KiB
Raw Permalink Blame History

Cheat-Sheet für Kubernetes-Beitragende

Eine Liste von oft-genutzten Ressourcen zum Beitragen zu Kubernetes; Tipps, Tricks und allgemeine Best-Practices innerhalb des Kubernetes-Projekts. Es ist als "TL;DR" (too long, didn't read - zu lang, nicht gelesen) oder Schnellreferenz nützlicher Informationen gedacht, um deine Beitragserfahrung auf GitHub besser zu machen.

Inhaltsverzeichnis

Hilfreiche Ressourcen

Wie man anfängt

SIGs und andere Gruppen

Community

Ablauf

Tests

  • Prow - Kubernetes CI/CD-System.
  • Test Grid - Ansicht historischer Tests und den zugehörigen Informationen.
  • Triage Dashboard - Aggregiert ähnliche Fehler zur besseren Fehlerbehandlung.

Wichtige Email-Adressen

Andere nützliche Links

Effektive Kommunikation auf GitHub

Seid exzellent zueinander

Als ersten Schritt sollte man sich mit dem Code of Conduct bekannt machen.

Beispiele für gute/schlechte Kommunikation

Wenn man ein Problem anspricht, oder Hilfe sucht, sollte man die Anfrage höflich formulieren:

🙂 “X kompiliert nicht, wenn ich Y mache, habt ihr Vorschläge dazu?

😞 “X geht nicht, fixt das!"

Beim Schließen eines PRs ist es sinnvoll eine freundliche und erklärende Nachricht hinzuzufügen weshalb dieser nicht die Mergeanforderungen erfüllt.

🙂 “Ich schließe diesen PR, da dieses Feature nicht den Use-Case X unterstützt. In der forgeschlagenen Form wäre es besser dies mit Y umzusetzen. Danke für deine Mitarbeit daran."

😞 “Warum folgt das nicht den API-Konventionen? Das sollte woanders gemacht werden!"

Einen Beitrag einreichen

Das CLA unterzeichnen

Bevor man einen Beitrag einreichen kann, muss das Contributor License Agreement (CLA) unterzeichnet werden. Das Kubernetes-Projekt kann nur einen Beitrag annehmen, wenn du oder deine Firma das CLA unterzeichnet haben.

Solltest du Probleme beim Unterzeichnen des CLAs haben, folge den CLA Troubleshooting Guidelines.

Erstellen von und Antworten auf Issues

GitHub Issues sind der meistgenutzte Weg um Dinge wie Bugreports und Enhancementrequests zu verfolgen, oder andere Probleme wie fehlschlagende Tests zu melden. Sie sind nicht als Anfragen für Usersupport gedacht. Für diese gibt es den Troubleshooting Guide, Stack-Overflow oder das Kubernetes-Forum.

Referenzen:

Erstellen eines Issues

  • Nutze ein Issue-Template, wenn eines zur Verfügung steht. Das korrekte Template hilft anderen Beitragenden auf deinen Issue zu antworten.
    • Folge allen Anweisungen im Template selbst.
  • Beschreibe den Issue detailliert.
  • Füge sinnvolle Labels hinzu. Wenn du dir nicht sicher bist, hilft der K8s-ci-robot Bot (Kubernetes CI bot) mit Antworten auf Issues, damit diese effektive verwaltet werden.
  • Sei selektiv beim Zuweisen von Issues zu Nutzern mit /assign @<username> oder /cc @<username>. Der Issue wird effektiver verwaltet, wenn sinnvolle Labels zugewiesen werden und weniger Menschen.

Antworten auf Issues

  • Wenn du an einem Issue arbeitest, hinterlasse einen Kommentar damit andere wissen, dass du daran arbeitest und doppelte Arbeit vermieden wird.
  • Falls du selbst eine Lösung findest, kommentiere den Issue mit einer Erklärung bevor du ihn schließt.
  • Referenzen auf andere PRs und Issues (oder andere Materialen) mit zum Beispiel: "ref: #1234" sind sinnvoll. Diese helfen Bezüge darauf zu finden, die an anderer Stelle bearbeitet wurden.

Öffnen eines Pull-Requests

Pull-Requests (PR) sind die meistgenutzte Variante um Code, Dokumentation oder andere Arten von Arbeit beizutragen, die in einem Git-Repository gespeichert werden können.

Referenzen:

Erstellen eines Pull-Requests

  • Folge den Anweisungen des Pull-Request-Templates, falls eines zur Verfügung steht. Es wird denen helfen, die auf den PR antworten.
  • Für triviale Fixes wie kaputte Links, Schreib- oder Grammatikfehler durchsuche das gesamte Dokument für andere potentielle Fehler. Mehrere PRs für kleine Fixes im gleichen Dokument sind unnötig.
  • Füge Referenzen auf verwandte Issues oder Issues die der PR lösen könnte hinzu.
  • Vermeide unnötig große Änderungen in einem einzelnen Commit. Zerteile stattdessen den PR in mehrere kleine, logische Commits. Das erleichter Reviews.
  • Kommentiere deinen eigenen PR wenn du meinst weitere Erklärungen sind nötig.
  • Sei selektiv beim Erstellen des PRs mit /assign @<username>. Zu viele Reviewer garantieren keinen schnelleren PR-Review.
  • Wenn der PR als "Work in progress" angesehen wird, füge ein [WIP] am Anfang des Titels hinzu oder nutze den /hold Befehl. Das stellt sicher, dass der PR nicht gemerged wird bis das [WIP] oder hold aufgehoben worden sind.
  • Falls dein PR noch nicht reviewed wurde, bitte schließe ihn nicht und öffne einen Neuen mit den gleichen Änderungen. Pinge deine Reviewer stattdessen in einem Kommentar mit @<github username> an.

Beispiel PR-Beschreibung

Ref. #3064 #3097
Alle Dateien im Besitz von SIG testing wurden von `/devel` zum neuen Ordner `/devel/sig-testing`
verschoben.

/sig contributor-experience
/cc @stakeholder1 @stakeholder2
/kind cleanup
/area developer-guide
/assign @approver1 @approver2 @approver3

Was steht in diesem PR:

  • Zeile 1 - Referenzen auf andere Issues oder PRs (#3064 #3097).
  • Zeile 2 - Eine kurze Beschreibung was in diesem PR getan wird.
  • Zeile 4 - SIG Zuweisung mit dem Befehl /sig contributor-experience..
  • Zeile 5 - Reviewer die Interesse an diesem spezifischen Issue oder PR haben könnten, werden mit /cc markiert.
  • Zeile 6 - Der /kind cleanup Befehl fügt ein Label hinzu, das Issues oder PRs als Aufräumen von Code, Prozessen oder technologischer Schuld kategorisiert.
  • Zeile 7 - Der /area developer-guide Befehl kategorisiert Issues oder PRs im Bezug zum Developerguide.
  • Zeile 9 - Der Befehl /assign fügt einen Approver zum PR hinzu. Ein Approver wird vom k8s-ci-robot vorgeschlagen und wird von der Liste der Eingentümer in der OWNERS Datei ausgewählt. file. Der Approver fügt das /approve Label zum PR hinzu nachdem dieser reviewed wurde.

Troubleshooting eines Pull-Requests

Nachdem ein PR vorgeschlagen wurde, wird eine Reihe an Test von der Kubernetes CL-Plattform Prow ausgeführt. Fall einer der Tests fehlschlägt, antwortet der K8s-ci-robot auf den PR mit Links zu den fehlgeschlagenen Tests und verfügbaren Logs.

Neue Commits zu diesem PR sorgen dafür dass diese Tests erneut ausgeführt werden.

Gelegentlich gibt es Probleme mit der Kubernetes CI-Plattform. Diese können aus verschiedenen Gründen auftreten, selbst wenn der Beitrag alle lokalen Tests besteht. Man kann einen neuen Testdurchlauf mit dem /retest Befehl auslösen.

Für mehr Informationen zum Troubleshooting von spezifischen Test, siehe den Testing Guide.

Labels

Kubernetes nutzt Labels zum sichten und kategorisieren von Issues und Pull Requests. Die richtigen Labels helfen dabei den Issue oder PR sinnvoller einzusortieren.

Referenzen:

Oft genutzte Labels:

Lokal arbeiten

Bevor man einen Pull-Request vorschlagen kann, muss man lokal etwas Arbeit leisten. Für Neueinsteiger zu git ist das Atlassian Git-Tutorial ein guter Einstiegspunkt. Alternativ ist das Git Magic Tutorical der Standford Uni eine gute multi-linguale Option.

Referenzen:

Branch-Strategie

Das Kubernetes-Projekt nutzt den Standardworkflow von GitHub, der sich "Fork and Pull" (auf Deutsch "abzweigen und ziehen") nennt. In Begriffen aus der Git-Welt wird dein persönlicher Fork als "origin" (auf Deutsch "Ursprung") und das eigentliche Projekt-Gitrepository als "upstream" (wörtlich "flussaufwärts") bezeichnet. Um deinen persönlichen Branch (origin) mit dem Projekt (upstream) aktuell zu halten, muss das innerhalb der lokalen Kopie konfiguriert werden.

Upstream hinzufügen

Füge upstream als sogenanntes remote hinzu und konfiguriere es so, dass man nicht dorthin pushen kann.

# Ersetze <upstream git repo> mit der Upstreamrepo-URL
# Beispiel:
#  https://github.com/kubernetes/kubernetes.git
#  git@github.com/kubernetes/kubernetes.git

git remote add upstream <upstream git repo>
git remote set-url --push upstream no_push

Das kann via git remote -v verifiziert werden, indem alle konfigurierten Remote-Repos aufgelistet werden.

Synchron halten von Forks

Hole alle Änderungen von upstream ab und "rebase" diese auf deinem lokalen Master Branch. Das wird dein lokales Repo mit dem upstream Projekt synchronisieren.

git fetch upstream
git checkout master
git rebase upstream/master

Das sollte minimal bevor der Erstellung eines neuen Branches für ein Feature oder einen Fix passieren.

git checkout -b myfeature

Commits squashen

Der Hauptzweck von Commits squashen("Commits zerquetschen") ist die Erstellung einer sauberen, lesbaren Githistorie oder eines Logs der Änderungen die gemacht wurden. Normal wird das in der letzten Phase einer PR Revision getan. Wenn du dir unsicher bist, ob du deine Commits squashen solltest, ist es besser mehrere zu lassen und es dem Urteil anderer Beitragenden zu überlassen, die als Reviewer und Approver für den PR zugeteilt wurden.