distribution spec
v1.1.0
Le projet SPEC de distribution OCI définit un protocole API pour faciliter et normaliser la distribution du contenu.
La spécification peut être trouvée ici.
Ce référentiel fournit également des types GO et des outils de conformité de registre. Les types GO et la validation doivent être compatibles avec la version actuelle de GO; Les sorties GO plus tôt ne sont pas prises en charge.
Documentation supplémentaire sur le fonctionnement de ce groupe:
La spécification de distribution OCI est étroitement liée au projet de spécification de format d'image OCI et au projet de spécification d'OCI d'exécution.
La spécification du format d'image OCI définit strictement les exigences d'une image OCI (image de conteneur), qui se compose d'un manifeste, d'un index d'image facultatif, d'un ensemble de couches de système de fichiers et d'une configuration. Le schéma des composants d'image OCI est entièrement pris en charge par les API définies dans la spécification de distribution OCI.
La spécification d'OCI Exécution définit comment exécuter correctement un "bundle de systèmes de fichiers" de conteneur qui adhère pleinement à la spécification du format d'image OCI. La spécification de l'exécution OCI est pertinente pour la spécification de distribution OCI en ce qu'ils prennent en charge les images OCI, et ce conteneur utilise les API définis dans la spécification de distribution OCI pour récupérer les images de conteneur pré-construites et les exécuter.
La spécification de distribution OCI (ce projet) est également conçue suffisamment génériquement pour être exploitée comme mécanisme de distribution pour tout type de contenu. Le format des manifestes téléchargés, par exemple, ne doit pas nécessairement adhérer à la spécification du format d'image OCI tant qu'il fait référence aux blobs qui comprennent un artefact donné.
Pour des questions sur la spécification de distribution OCI, veuillez consulter la FAQ.
Pour les questions générales sur OCI, veuillez consulter la FAQ sur le site OCI.
Les jalons GitHub disposent du chemin vers les améliorations futures.
Le projet de spécification de distribution comprend un processus et une API pour le prototypage et les extensions de test à l'API de distribution.
Nous invitons les contributions, les commentaires et les critiques à ces extensions. Ces extensions ne feront qu'avant avec un soutien important des registres, des clients du registre et des utilisateurs.
Veuillez consulter ici pour plus de détails.
Le développement se produit sur GitHub pour la spécification. Les problèmes sont utilisés pour les bogues et les éléments exploitables et des discussions plus longues peuvent se produire sur la liste de diffusion.
La spécification et le code sont concédés sous licence Apache 2.0 trouvés dans le fichier LICENSE de ce référentiel.
Le projet accueille les soumissions, mais veuillez faire savoir à tout le monde sur quoi vous travaillez.
Avant d'entreprendre une modification non triviale de cette spécification, envoyez le courrier à la liste de diffusion pour discuter de ce que vous prévoyez de faire. Cela donne à chacun une chance de valider la conception, aide à prévenir la duplication de l'effort et garantit que l'idée s'adapte. Il garantit également que la conception est saine avant que le code ne soit écrit; Une demande de traction GitHub n'est pas le lieu de discussions de haut niveau.
Les fautes de frappe et les erreurs grammaticales peuvent aller directement à une demande de traction. En cas de doute, commencez sur la liste de diffusion.
Veuillez consulter le ReadMe du référentiel OCI ORG pour les informations les plus à jour sur les calendriers de la réunion des contributeurs et du maintecteur OCI. Vous pouvez également trouver des liens vers les agendas et le procès-verbal des réunions pour toutes les réunions antérieures.
Vous pouvez vous abonner et rejoindre la liste de diffusion sur les groupes Google.
La discussion OCI se produit dans les salles de chat suivantes, qui sont toutes pontées ensemble:
Pour maintenir la cohérence tout au long des fichiers Markdown dans les spécifications de conteneurs ouvertes, tous les fichiers doivent être formatés une phrase par ligne. Cela corrige deux choses: cela facilite la difficulté avec Git et il résout les combats sur la longueur d'emballage des lignes. Par exemple, ce paragraphe s'étendra sur trois lignes dans la source Markdown.
La signature est une ligne simple à la fin de l'explication du patch, qui certifie que vous l'avez écrit ou que vous avez le droit de le transmettre en tant que patch open-source. Les règles sont assez simples: si vous pouvez certifier ce qui précède (sur 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.
Ensuite, vous ajoutez simplement une ligne à chaque message Git Commit:
Signed-off-by: Jane Smith <[email protected]>
Utilisation de votre vrai nom (désolé, pas de pseudonymes ou de contributions anonymes.)
Vous pouvez ajouter le signe lors de la création du GIT Commit via git commit -s .
Suivre à la maison simple pour l'histoire de Git propre. En savoir plus sur la façon de rédiger un message Git Commit ou la section de discussion de git-commit(1) .
