distribution spec
v1.1.0
Das OCI Distribution Spec -Projekt definiert ein API -Protokoll, um die Verteilung des Inhalts zu erleichtern und zu standardisieren.
Die Spezifikation finden Sie hier.
Dieses Repository bietet auch GO -Typen und Registrierungskonformance -Tools. Die GO -Typen und die Validierung sollten mit der aktuellen GO -Version kompatibel sein. Frühere GO -Veröffentlichungen werden nicht unterstützt.
Zusätzliche Dokumentation darüber, wie diese Gruppe funktioniert:
Die OCI -Verteilungsspezifikation ist eng mit dem OCI -Bildformat -Spezifikationsprojekt und dem OCI -Laufzeitspezifikationsprojekt verbunden.
Die OCI -Bildformatspezifikation definiert streng die Anforderungen für ein OCI -Bild (Containerbild), das aus einem Manifest, einem optionalen Bildindex, einer Reihe von Dateisystemebenen und einer Konfiguration besteht. Das Schema für OCI -Bildkomponenten wird durch die in der OCI -Verteilungsspezifikation definierten APIs vollständig unterstützt.
Die OCI -Laufzeitspezifikation definiert, wie ein Container -Dateisystempaket ordnungsgemäß ausgeführt wird, das sich vollständig an der OCI -Bildformatspezifikation hält. Die OCI-Laufzeitspezifikation ist für die OCI-Verteilungsspezifikation relevant, da beide OCI-Bilder unterstützen und dass Container-Runtimes die in der OCI-Verteilungsspezifikation definierten APIs verwenden, um vorgefertigte Containerbilder abzurufen und auszuführen.
Die OCI -Verteilungsspezifikation (dieses Projekt) ist ebenfalls generell genug entwickelt, um als Verteilungsmechanismus für jede Art von Inhalten genutzt zu werden. Das Format von hochgeladenem Manifests zeigt beispielsweise nicht unbedingt die Spezifikation des OCI -Bildformates, solange es die Blobs verweist, die ein bestimmtes Artefakt umfassen.
Fragen zur OCI -Verteilungsspezifikation finden Sie in den FAQ.
Für allgemeine Fragen zu OCI finden Sie die FAQs auf der OCI -Website.
Die Github -Meilensteine stellen den Weg zu den zukünftigen Verbesserungen aus.
Das Verteilungsspezifikationsprojekt enthält einen Prozess und eine API für Prototyping und Testverlängerungen zur Verteilungs -API.
Wir laden Beiträge, Kommentare und Bewertungen zu diesen Erweiterungen ein. Diese Erweiterungen werden nur erhebliche Unterstützung durch Registrierung, Registrierungskunden und Benutzer vorantreiben.
Weitere Informationen finden Sie hier.
Die Entwicklung findet auf GitHub für die Spezifikation statt. Probleme werden für Fehler und umsetzbare Elemente verwendet, und längere Diskussionen können in der Mailingliste stattfinden.
Die Spezifikation und der Code sind unter der in der LICENSE dieses Repository gefundenen Apache 2.0 -Lizenz lizenziert.
Das Projekt begrüßt Einsendungen, aber bitte lassen Sie alle wissen, woran Sie arbeiten.
Bevor Sie eine nicht triviale Änderung dieser Spezifikation vornehmen, senden Sie E -Mail an die Mailingliste, um zu besprechen, was Sie vorhaben. Dies gibt jedem die Möglichkeit, das Design zu validieren, zu verhindern, dass die Vervielfältigung von Anstrengungen vorliegt, und stellt sicher, dass die Idee passt. Es garantiert auch, dass das Design so gut ist, bevor der Code geschrieben wird. Ein Github Pull-Request ist nicht der Ort für hochrangige Diskussionen.
Tippfehler und grammatikalische Fehler können direkt zu einer Pull-Request gehen. Im Zweifelsfall beginnen Sie mit der Mailingliste.
Weitere Informationen zu OCI-Mitwirkenden und Inhaberbesprechungsplänen finden Sie im OCI Org Repository Readme. Für alle früheren Besprechungen finden Sie auch Links zu Begegnungagenden und Minuten.
Sie können sich der Mailingliste in Google Groups abonnieren und anschließen.
Die OCI -Diskussion findet in den folgenden Chatrooms statt, die alle miteinander überbrückt werden:
Um die Konsistenz in den Markdown -Dateien in der Spezifikation für den Öffnen von Container zu behalten, sollten alle Dateien einen Satz pro Zeile formatiert werden. Dies behebt zwei Dinge: Es erleichtert Git und löst die Kämpfe über die Länge der Linienverpackung. Beispielsweise umfasst dieser Absatz drei Zeilen in der Markdown -Quelle.
Die Anmeldung ist eine einfache Zeile am Ende der Erklärung für den Patch, der bescheinigt, dass Sie sie geschrieben haben oder auf andere Weise das Recht haben, sie als Open-Source-Patch weiterzugeben. Die Regeln sind ziemlich einfach: Wenn Sie die unten bescheinigen können (von DeveloperCertificate.org):
Developer Certificate of Origin
Version 1.1
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
660 York Street, Suite 102,
San Francisco, CA 94110 USA
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
Dann fügen Sie jeder Git -Commit -Nachricht eine Zeile hinzu:
Signed-off-by: Jane Smith <[email protected]>
Verwenden Sie Ihren richtigen Namen (Entschuldigung, keine Pseudonyme oder anonymen Beiträge.)
Sie können die Unterschreiber bei der Erstellung des Git Commit über git commit -s hinzufügen.
Einfache Haushaltsführung für saubere Git-Geschichte. Lesen Sie mehr darüber, wie Sie eine Git-Commit-Nachricht oder den Diskussionsabschnitt von git-commit(1) schreiben.
