image spec
v1.1.0
O projeto OCI Image Format cria e mantém a especificação de formato de imagem do contêiner de remessa de software (OCI Image Format).
A especificação pode ser encontrada aqui.
Este repositório também fornece tipos Go, ferramentas de validação intra-blob e esquema JSON. Os tipos e a validação do Go devem ser compatíveis com a versão atual do Go; versões anteriores do Go não são suportadas.
Documentação adicional sobre como este grupo funciona:
O projeto parceiro do OCI Image Format é o projeto OCI Runtime Spec. A especificação de tempo de execução descreve como executar um "pacote de sistema de arquivos" descompactado em disco. Em um alto nível, uma implementação do OCI baixaria uma imagem do OCI e depois descompactaria essa imagem em um pacote do sistema de arquivos do OCI Runtime. Neste ponto, o OCI Runtime Bundle seria executado por um OCI Runtime.
Todo esse fluxo de trabalho oferece suporte à UX que os usuários esperam de mecanismos de contêiner como Docker e rkt: principalmente, a capacidade de executar uma imagem sem argumentos adicionais:
Para suportar esta UX, o formato de imagem OCI contém informações suficientes para iniciar o aplicativo na plataforma de destino (por exemplo, comando, argumentos, variáveis de ambiente, etc.).
O Projeto OCI Distribution Spec define um protocolo API para facilitar e padronizar a distribuição de conteúdo. Esta API inclui suporte para enviar e extrair imagens OCI para um registro compatível com OCI.
P: O que acontece com os formatos de imagem AppC ou Docker?
R: Os formatos existentes podem continuar a ser um campo de provas para tecnologias, conforme necessário. O projeto OCI Image Format se esforça para fornecer uma especificação aberta confiável que possa ser compartilhada entre diferentes ferramentas e evoluída por anos ou décadas de compatibilidade; como o formato deb e rpm possuem.
Encontre mais perguntas frequentes no site da OCI.
Os marcos do GitHub traçam o caminho para melhorias futuras.
O desenvolvimento acontece no GitHub para 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 são licenciados sob a licença Apache 2.0 encontrada no arquivo LICENSE deste repositório.
O projeto aceita inscrições, mas informe a todos no que você está trabalhando.
Antes de realizar uma alteração não trivial nesta especificação, envie um e-mail para a lista de discussão para discutir o que você planeja fazer. Isto dá a todos a oportunidade de validar o design, ajuda a evitar a duplicação de esforços e garante que a ideia se encaixa. Também garante que o design esteja correto antes que o código seja escrito; uma solicitação pull do GitHub não é o local para discussões de alto nível.
Erros de digitação e gramaticais podem ir direto para uma solicitação pull. Em caso de dúvida, comece na lista de discussão.
Consulte o README do repositório organizacional do OCI para obter as informações mais atualizadas sobre os cronogramas de reuniões dos contribuidores e mantenedores do OCI. Você também pode encontrar links para agendas de reuniões e atas de todas as reuniões anteriores.
Você pode se inscrever e ingressar na lista de e-mails dos Grupos do Google.
Para manter a consistência em todos os arquivos Markdown na especificação Open Container, todos os arquivos devem ser formatados em uma frase por linha. Isso corrige duas coisas: facilita a comparação com o git e resolve brigas sobre o comprimento da quebra de linha. Por exemplo, este parágrafo abrangerá três linhas na fonte Markdown.
A assinatura é uma linha simples no final da explicação do patch, que certifica que você o escreveu ou tem o direito de repassá-lo como um patch de código aberto. As regras são bem simples: se você puder certificar o seguinte (em 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.
então você apenas adiciona uma linha a cada mensagem de commit do git:
Signed-off-by: Joe Smith <[email protected]>
usando seu nome verdadeiro (desculpe, sem pseudônimos ou contribuições anônimas).
Você pode adicionar a aprovação ao criar o git commit via git commit -s .
Manutenção simples para um histórico git limpo. Leia mais sobre Como escrever uma mensagem de commit do Git ou a seção de discussão de git-commit(1) .
