AgentBaker
v0.20230216.5
Agentbaker ist eine Sammlung von Komponenten, die zur Bereitstellung von Kubernetes -Knoten in Azure verwendet werden.
Agentbaker hat ein paar Stücke
Der Hauptverbraucher von Agentbaker ist Azure Kubernetes Service (AKS).
AKS verwendet AgentBaker, um Linux- und Windows Kubernetes -Knoten bereitzustellen.
Entwicklungsagent für AgentBaker erfordert einige grundlegende Voraussetzungen:
Run make -C hack/tools install um alle Entwicklungstools zu installieren.
Wenn Sie Code oder Artefakte ändern, die zum Generieren benutzerdefinierter Daten oder benutzerdefinierter Nutzlast von Skriptweiterungen verwendet werden, sollten Sie make .
Dieser Code wird neu ausgeführt, um statische Dateien in den Go-Code einzubetten, was tatsächlich zur Laufzeit verwendet wird.
Dies führt zusätzlich Einheitstests (gleichwertig von go test ./... ) aus und regeneriert Snapshot TestData.
Wir verwenden Golangci-Lint, um den Stil durchzusetzen.
Run make -C hack/tools install , um den Linter zu installieren.
Rennen ./hack/tools/bin/golangci-lint run
Wir haben derzeit viele Misserfolge, von denen wir hoffen, dass sie eliminieren.
Wir haben einen Job, um Golangci-Lint auf Pull-Anfragen zu betreiben.
Dieser Job verwendet die Linter "No-New-Outsues" -Funktion.
Solange PRs keine neuen Net -neuen Probleme einführen, sollten sie bestehen.
Wir haben auch einen Stining -Job, um den Bekanntheitsgrad -Nachrichtenstil durchzusetzen.
Wir halten uns an konventionelle Commits.
Ziehen Sie Pull -Anfragen mit einzelnen Commits vor.
Um In -Progress -Commits zu beseitigen, können Sie git rebase -i verwenden, um Commits zu fixieren.
Weitere Informationen finden Sie in der Git -Dokumentation.
Der meiste Code kann mit Vanilla GO -Unit -Tests getestet werden.
Bitte besuchen Sie den offiziellen Github -Link für weitere Informationen. Unten finden Sie einen kurzen Anwendungsfall.
Shellspec wird als Framework für Unit -Test verwendet. Es gibt 2 Optionen, um es zu installieren.
Shellspec ist bereits im Makefile enthalten. Sie können es einfach installieren, indem Sie ausführen make tools-install oder in Root (/AgentBaker) -Verzeichnungen make generate .
HINWEIS: make generate installiert und führt die ShellSpec -Tests aus.
Wenn Sie es in Ihrem lokalen Computer installieren möchten, führen Sie bitte curl -fsSL https://git.io/shellspec | sh .
Standardmäßig sollte es in ~/.local/lib/shellspec installiert werden. Bitte fügen Sie es für Ihre Bequemlichkeit an den $ path an. Beispiel für den Befehl export PATH=$PATH:~/.local/lib/shellspec .
Sie müssen die Datei xxx_spec.sh für den Test schreiben.
Beispielsweise ist AgentBaker/spec/parts/linux/cloud-init/artifacts/cse_install_spec.sh eine Testdatei für AgentBaker/parts/linux/cloud-init/artifacts/cse_install.sh
Um alle Tests im Ordner agentbaker auszuführen, führen Sie einfach bash ./hack/tools/bin/shellspec im Root (/agentbaker) Verzeichnis aus.
bash ./hack/tools/bin/shellspec -x => Mit -x zeigt es ausführliche Spuren zum Debuggen.bash ./hack/tools/bin/shellspec -E "<test name>" => Sie können einen einzelnen Testfall mit -E und den Testnamen ausführen. Zum Beispiel bash ./hack/tools/bin/shellspec -E "returns downloadURIs.ubuntu."r2004".downloadURL of package runc for UBUNTU 20.04" Sie können auch -xE für eine ausführliche Spur für einen einzelnen Testfall durchführen.bash ./hack/tools/bin/shellspec "path to xxx_spec.sh" => Durch Bereitstellen eines vollständigen Pfads eine bestimmte Spezifikationsdatei können Sie nur diese Spezifikationsdatei anstelle aller Spezifikationsdateien im AgentBaker -Projekt ausführen. Zum Beispiel bash ./hack/tools/bin/shellspec "spec/parts/linux/cloud-init/artifacts/cse_install_spec.sh" Wir haben auch Snapshot -Datentests, die die Ausgabe von Schlüssel -APIs als Dateien auf der Festplatte speichern.
Wir können manuell überprüfen, ob der Snapshot -Inhalt korrekt aussieht.
Wir haben jetzt Unit -Tests, die den Inhalt direkt validieren können, ohne generierte Dateien auf der Festplatte zu lassen.
Beispiele siehe ./pkg/agent/baker_test.go (suchen Sie nach dynamic-config-dir um eine Validierungsprobe anzuzeigen.).
Checkout des E2E -Verzeichnisses.
Dieses Projekt begrüßt Beiträge und Vorschläge. In den meisten Beiträgen müssen Sie einer Mitarbeiters Lizenzvereinbarung (CLA) zustimmen, in der Sie erklären, dass Sie das Recht haben und uns tatsächlich tun, um uns die Rechte zu gewähren, Ihren Beitrag zu verwenden. Weitere Informationen finden Sie unter https://cla.opensource.microsoft.com.
Wenn Sie eine Pull -Anfrage einreichen, bestimmt ein CLA -Bot automatisch, ob Sie einen CLA angeben und die PR angemessen dekorieren müssen (z. B. Statusprüfung, Kommentar). Befolgen Sie einfach die vom Bot bereitgestellten Anweisungen. Sie müssen dies nur einmal über alle Repos mit unserem CLA tun.
Dieses Projekt hat den Microsoft Open Source -Verhaltenscode übernommen. Weitere Informationen finden Sie im FAQ oder wenden Sie sich an [email protected] mit zusätzlichen Fragen oder Kommentaren.
Eine CGManifest -Datei ist eine JSON -Datei, mit der Komponenten manuell registriert werden, wenn der Komponententyp nicht durch Governance unterstützt wird. Der Dateiname lautet "cgManifest.json" und Sie können so viele haben, wie Sie benötigen, und können überall in Ihrem Repository sein.
Dateipfad: ./vhdbuilder/cgmanifest.json
Referenz: https://docs.opensource.microsoft.com/tools/cg/cgmanifest.html
Paket:
