distribution spec
v1.1.0
O projeto de especificação de distribuição da OCI define um protocolo da API para facilitar e padronizar a distribuição do conteúdo.
A especificação pode ser encontrada aqui.
Este repositório também fornece tipos de GO e ferramentas de conformidade do registro. Os tipos GO e a validação devem ser compatíveis com a versão atual do Go; Os lançamentos GO anterior não são suportados.
Documentação adicional sobre como esse grupo opera:
A especificação de distribuição da OCI está intimamente relacionada ao projeto de especificação de formato de imagem OCI e ao projeto de especificação de tempo de execução da OCI.
A especificação de formato de imagem OCI define estritamente os requisitos para uma imagem OCI (imagem do contêiner), que consiste em um manifesto, um índice de imagem opcional, um conjunto de camadas do sistema de arquivos e uma configuração. O esquema para componentes da imagem OCI é totalmente suportado pelas APIs definidas na especificação de distribuição da OCI.
A especificação do tempo de execução da OCI define como executar corretamente um "pacote de sistemas de arquivos" corretamente que adere totalmente à especificação do formato de imagem OCI. A especificação de tempo de execução da OCI é relevante para a especificação de distribuição da OCI, pois ambos suportam imagens OCI e que os tempos de execução do contêiner usam as APIs definidas na especificação de distribuição da OCI para buscar imagens de contêineres pré-construídas e executá-las.
A especificação de distribuição da OCI (este projeto) também foi projetada de maneira genericamente suficiente para ser alavancada como um mecanismo de distribuição para qualquer tipo de conteúdo. O formato de manifestos carregados, por exemplo, não precisa necessariamente aderir à especificação do formato de imagem OCI, desde que faça referência aos blobs que compreendem um determinado artefato.
Para perguntas sobre a especificação de distribuição da OCI, consulte as perguntas frequentes.
Para perguntas gerais sobre OCI, consulte as perguntas frequentes no site da OCI.
Os marcos do Github estabelecem o caminho para as melhorias futuras.
O projeto de especificação de distribuição inclui um processo e API para prototipagem e teste de extensões da API de distribuição.
Convidamos contribuições, comentários e análises para essas extensões. Essas extensões só avançarão com suporte significativo de registros, clientes de registro e usuários.
Por favor, veja aqui para mais detalhes.
O desenvolvimento acontece no GitHub para as especificações. Os problemas são usados para bugs e itens acionáveis e discussões mais longas podem acontecer na lista de discussão.
A especificação e o código estão licenciados sob a licença Apache 2.0 encontrada no arquivo LICENSE deste repositório.
O projeto recebe as inscrições, mas informe a todos no que você está trabalhando.
Antes de realizar uma alteração não trivial para esta especificação, envie e -mails para a lista de discussão para discutir o que você planeja fazer. Isso dá a todos a chance de validar o design, ajuda a evitar a duplicação de esforços e garante que a ideia se encaixe. Também garante que o design seja sólido antes da gravação do código; Uma solicitação Pull-Pull do Github não é o lugar para discussões de alto nível.
Erros de digitação e erros gramaticais podem ir direto para uma solicitação de tração. Em caso de dúvida, comece na lista de correspondência.
Consulte o OCI Org Repository ReadMe para obter as informações mais atualizadas sobre os cronogramas de colaboradores da OCI e mantenedores. Você também pode encontrar links para atender às agendas e minutos para todas as reuniões anteriores.
Você pode se inscrever e entrar na lista de discussão nos grupos do Google.
A discussão da OCI acontece nas salas de bate -papo a seguir, que são todas juntas:
Para manter a consistência em todos os arquivos de marcação na especificação de contêiner aberto, todos os arquivos devem ser formatados uma frase por linha. Isso corrige duas coisas: facilita a diferença com o Git e resolve brigas sobre o comprimento de embalagem de linhas. Por exemplo, este parágrafo abrange três linhas na fonte de marcação.
A assinatura é uma linha simples no final da explicação para o patch, que certifica que você a escreveu ou de outra forma tem o direito de transmiti-lo como um patch de código aberto. As regras são bem simples: se você pode certificar o abaixo (de DevelopCertificate.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.
Então você apenas adiciona uma linha a cada mensagem Git Commit:
Signed-off-by: Jane Smith <[email protected]>
Usando seu nome verdadeiro (desculpe, sem pseudônimos ou contribuições anônimas.)
Você pode adicionar a assinatura ao criar o Commit Git via git commit -s .
Manutenção de casas simples para o histórico de Git limpo. Leia mais sobre como escrever uma mensagem de comprometimento Git ou a seção de discussão do git-commit(1) .
