liber. Manuais
Manuais›Arquivos›Arquivos no GitHub

Arquivos no GitHub

O mesmo porteiro, na estante onde a produção versiona os originais: um repositório vira pasta, cada envio vira commit, cada revisão tem SHA — e o link compartilhado, pela primeira vez, não fura o portão.

Visão geral

Este app é um corpo do chassi Cloud Files — o mesmo do Dropbox e do Drive. A disciplina é herdada e idêntica: acesso por grupos pasta a pasta, multiempresa, espelho de metadados, tags e vínculos, mapear é de administrador, escrever exige grupo de escrita. O que muda é o vocabulário, traduzido do Git:

No LiberNo GitHub
PastaUm repositório (ID externo = dono/repositório), com subpasta opcional no campo Caminho (/ sozinho = a raiz) e Branch (vazio = a padrão).
EnviarUm commit liber: arquivo.pdf na branch da pasta — um por arquivo: mandou cinco de uma vez, são cinco commits. Nunca sobrescreve: nome repetido vira arquivo (1).ext.
RevisãoO SHA do blob — versionamento de graça, mudou o conteúdo, mudou o SHA.
Link compartilhadoA página do arquivo no GitHub — só abre para quem enxerga o repositório. Por isso não expira: a ficha registra honestamente "sem validade".
Formulário de um repositório mapeado, com dono/repositório no ID externo, a branch e os grupos de leitura e escrita.
O repositório como pasta: dono/repositório, branch, e a mesma decisão de sempre — quem lê, quem escreve.

Configuração

  1. Gere um fine-grained personal access token. Ele não nasce na organização — o Developer settings dela só tem OAuth Apps, GitHub Apps e Publisher Verification. Nasce na conta pessoal de um membro da organização: foto do perfil‣Settings‣fim da barra lateral‣Developer settings‣Personal access tokens‣Fine-grained tokens (atalho: github.com/settings/personal-access-tokens/new).
  2. No formulário do token, aponte a empresa: Resource owner = a organização (não a conta pessoal), Repository access nos repositórios que serão mapeados e Contents: Read and write nas permissões. Anote a validade — token vencido para sync e envio até que se cole um novo na Conta. Se a organização aparecer bloqueada ou o token ficar pendente, um owner libera em Organização‣Settings‣Third-party Access‣Personal access tokens (roteiro completo no NOTES.md do módulo).
  3. Preencha GitHub‣Configuração‣Conta e use Testar conexão. Uma conta por empresa.
  4. Como administrador, mapeie em GitHub‣Configuração‣Repositórios: o ID externo como dono/repositório, a subpasta (Caminho, / para a raiz), a branch e os grupos.

O dia a dia

Sincronizar espelha a árvore da branch (a subpasta mapeada, recursiva ou não); baixar desce pelo Odoo com o portão conferido; enviar commita pelo menu GitHub‣Enviar. Tags e vínculos com contatos e produtos são os mesmos da casa — um contrato no Dropbox e seus originais no GitHub apontam para o mesmo autor e o mesmo título.

O envio vai de braçada: o campo de arquivos do assistente aceita um ou muitos de uma vez — escolhidos no seletor do sistema ou arrastados para dentro dele —, e cada arquivo vira o seu próprio commit na branch da pasta. O Odoo não guarda cópia depois do envio e o espelho sincroniza na hora, já com os SHAs novos.

Lista de arquivos de um repositório espelhado, com o SHA na coluna de revisão.
O espelho do repositório: cada arquivo com seu SHA — mudou o conteúdo, o sync denuncia.

Limitações conhecidas

  • Sem miniaturas — baixar cada imagem só para encolher não vale a banda num host de código.
  • Sem data de modificação por arquivo no espelho (seria uma chamada de API por arquivo; o SHA já denuncia mudança).
  • Arquivos em LFS aparecem com o tamanho do ponteiro, não do conteúdo.
Ver também