Skip to Content
Building OsSoftware personalizado a partir de repositórios de origem

Software personalizado a partir de repositórios de origem

Receitas OpenFactory podem referenciar um repositório Git como entrada de pacote personalizado em builders de imagem suportados. É um caminho sensível à cadeia de suprimentos: repositório, revisão resolvida, instruções de empacotamento, dependências de build e pacote produzido exigem revisão.

O suporte é específico de alvo. Builds de source-package são rejeitados em alguns builders, incluindo caminhos atuais Raspberry Pi e Proxmox. Confirme disponibilidade na receita normalizada e no plano de build antes de prometer que um pacote será produzido.

Formato da receita

Entradas de pacote personalizado ficam em os.custom_packages:

{
  "os": {
    "custom_packages": [
      {
        "name": "my-agent",
        "git_url": "https://github.com/example/my-agent.git",
        "branch": "release-1.x"
      }
    ]
  }
}

O schema aceita nome de branch, não campo de commit imutável. Para release controlada, registre o commit exato resolvido pelo build e faça desse commit parte da proveniência retida. Branch móvel sozinha não é entrada reproduzível.

Prepare o repositório

O caminho de pacote atual espera metadados de empacotamento nativos adequados ao alvo. Exemplos comuns são diretório Debian debian/ ou spec RPM. Comportamento exato do builder e versões de alvo suportadas podem mudar; valide um pacote mínimo no ambiente implantado em vez de depender de tabela estática de compatibilidade.

Para empacotamento Debian, revise pelo menos:

  • debian/control para identidade source/binary e dependências;
  • debian/changelog para versão do pacote;
  • debian/rules e outros scripts maintainer executáveis;
  • manifests de install e units systemd; e
  • licenciamento e material third-party embutido.

Para empacotamento RPM, revise sources, build requirements, scriptlets, file list e metadados de licença do spec.

Nunca assuma que propriedade do repositório torna seus scripts de build seguros. Builds de pacote executam lógica de origem e empacotamento não confiável dentro do limite de isolamento da infraestrutura de build.

Outros controles de pacote

Pacotes nativos

Use os.packages para pacotes já fornecidos pela distribuição selecionada ou repositório explicitamente configurado:

{
  "os": {
    "packages": ["curl", "jq"]
  }
}

Overrides de pacote

os.package_overrides pode declarar intenção add, remove ou replace:

{
  "os": {
    "package_overrides": [
      {"name": "nano", "action": "replace", "replacement": "neovim"},
      {"name": "telnet", "action": "remove"}
    ]
  }
}

Override não prova que a resolução de dependências o honrou. Verifique inventário final de pacotes e asserções de presença/ausência.

Repositórios adicionais

os.extra_repos é entrada avançada. Não adicione repositório HTTP não assinado como em exemplos antigos. Integração aprovada de repositório precisa transporte HTTPS, chave de assinatura fixada, enforcement de assinatura, metadados de release adequados ao gerenciador de pacotes e política documentada de propriedade e update. Se esses controles de confiança não puderem ser representados pelo builder atual, não use o repositório.

Evidência de aceitação

Para cada pacote personalizado, retenha:

  • URL do repositório e commit resolvido;
  • revisão de origem e licença declarada;
  • snapshot de ambiente de build e dependências;
  • logs de build e nome/versão/arquitetura do pacote resultante;
  • digest do pacote e evidência de assinatura de repositório quando aplicável;
  • inventário final da imagem mostrando o pacote instalado;
  • smoke tests de serviço ou executável; e
  • comportamento de remoção e upgrade.

Estágio bem-sucedido de source-package não basta. O build da imagem pode falhar depois em consumir o pacote, e pacote instalado ainda pode ser inutilizável.

Solução de problemas

  • Metadados de empacotamento rejeitados: valide o pacote nativo localmente com a mesma release e arquitetura de distribuição.
  • Dependência de build faltando: use dependências disponíveis de repositórios aprovados para aquele alvo; não busque silenciosamente binários arbitrários em script maintainer.
  • Pacote ausente da imagem: compare o nome do pacote binário produzido com o pedido de install normalizado e inventário final.
  • Versão não mudou: atualize metadados de versão nativos e confirme que o novo commit de origem foi resolvido.
  • Serviço falhou: inspecione unit, dependências de runtime, permissões e logs do guest; adicione asserção em nível de comportamento antes de reconstruir.
Imagens baseImagens desktop