Integração com Git

Permita que os usuários clonem, façam pull e push dos seus projetos com Git por meio do git-bridge.

A integração com Git está disponível atualmente em ayaka-notes/overleaf.

Este recurso foi desenvolvido inicialmente por ayaka-notes/ayakaleaf-pro.

1. Ativar o git-bridge (apenas para usuários do Toolkit)

   Se você estiver usando o Toolkit, ative o git-bridge definindo o seguinte em seu config/overleaf.rc:

   config/overleaf.rc

   GIT_BRIDGE_ENABLED=true
   

   O Toolkit a ignora, a menos que SERVER_PRO=true também esteja definida. Nada mais é necessário: o próprio Toolkit define GIT_BRIDGE_HOST, GIT_BRIDGE_PORT e V1_HISTORY_URL para o contêiner sharelatex, então pule as duas etapas do Docker Compose abaixo. Execute bin/up para recriar os contêineres.

2. Adicionar o contêiner git-bridge (apenas para usuários do Docker-compose)

   Para usuários que executam um docker-compose.yml personalizado, adicione a seguinte configuração de contêiner ao seu arquivo compose:

   docker-compose.yml (git-bridge service)

   git-bridge:
       restart: always
       image: ghcr.io/ayaka-notes/overleaf-pro/git-bridge:6.3.2 # tag should match the `sharelatex` container tag
       volumes:
           - ~/git_bridge_data:/data/git-bridge
       container_name: git-bridge
       expose:
           - "8000"
       environment:
           GIT_BRIDGE_API_BASE_URL: "http://sharelatex:3000/api/v0/" 
           GIT_BRIDGE_OAUTH2_SERVER: "http://sharelatex"
           GIT_BRIDGE_POSTBACK_BASE_URL: "http://git-bridge:8000"
           GIT_BRIDGE_ROOT_DIR: "/data/git-bridge"
       user: root
       command: ["/server-pro-start.sh"]
   

   Use a mesma tag da imagem sharelatex. O MCP Server (v6.3.1 e posteriores) faz parte da imagem sharelatex e é habilitado junto com a integração com Git, então não precisa de nenhum contêiner extra.

3. Atualizar a configuração do contêiner sharelatex

   Você também precisará vincular o contêiner git-bridge ao contêiner sharelatex e definir as seguintes variáveis de ambiente; preste atenção a V1_HISTORY_URL:

   docker-compose.yml (sharelatex service)

   sharelatex:
       links:
           - git-bridge
       environment:
            GIT_BRIDGE_ENABLED: true
            GIT_BRIDGE_HOST: "git-bridge"
            GIT_BRIDGE_PORT: "8000"
            # We use v1 now, if you used to set V1_HISTORY_URL, please update now
            V1_HISTORY_URL: "http://sharelatex:3100/api"
   
4. Autenticação

   Ao autenticar um cliente git, os usuários precisam de um Personal Access Token. Os usuários podem gerenciar Personal Access Tokens pela interface da aplicação (consulte a documentação):

   

   Personal Access Token da integração com Git

5. Monitoramento e considerações sobre recursos

   Recomendamos monitorar os recursos do seu host depois de ativar o git-bridge. O aumento de carga dependerá de:

   • o número de usuários que acessam o recurso
   • os tipos de projetos hospedados na sua instância (projetos maiores geralmente consomem mais recursos)

​

Transferência (swap) de projetos para o S3

A integração com Git armazena em disco um repositório git completo para cada projeto clonado por um usuário. Se você tiver espaço em disco limitado, pode ativar um job de swap que moverá os repositórios menos usados para o AWS S3. Se um repositório transferido for necessário novamente, ele será movido de volta para o disco. As seguintes variáveis de ambiente controlam o job de swap:

Nome	Descrição
GIT_BRIDGE_SWAPSTORE_TYPE	Defina como “s3” para ativar o job de swap.
GIT_BRIDGE_SWAPSTORE_AWS_ACCESS_KEY	Sua chave de acesso da AWS
GIT_BRIDGE_SWAPSTORE_AWS_SECRET	Seu segredo da AWS
GIT_BRIDGE_SWAPSTORE_S3_BUCKET_NAME	Este bucket conterá os repositórios git compactados
GIT_BRIDGE_SWAPSTORE_AWS_REGION	A região do bucket
GIT_BRIDGE_SWAPJOB_MIN_PROJECTS	Quantos projetos manter em disco, no mínimo. - Padrão: 50
GIT_BRIDGE_SWAPJOB_LOW_GIB	Limite inferior para o swap. O job de swap moverá projetos até que o uso do disco fique abaixo desse valor. - Padrão: 128 GB
GIT_BRIDGE_SWAPJOB_HIGH_GIB	Limite superior para o swap. O job de swap começará a transferir quando o uso do disco atingir esse valor. - Padrão: 256 GB
GIT_BRIDGE_SWAPJOB_INTERVAL_MILLIS	O intervalo de tempo entre as verificações de uso do disco e a execução do job de swap. - Padrão: 3600000 ms = 1 hora

​

Perguntas e respostas

Se eu compartilhar meu projeto com outra pessoa, como funciona o modelo de permissões do Git Bridge?

Usuários com acesso somente leitura podem apenas clonar este projeto; usuários com acesso de leitura e gravação podem clonar e fazer push nos projetos. Observação: os usuários precisam estar logados para participar deste projeto.

Como clonar um projeto e qual nome de usuário e senha devo usar?

No editor, abra Integrations na barra lateral esquerda e clique em Git integration. Ali é exibido o comando de clonagem, no formato:

git clone https://<your-overleaf>/git/<project_id>

Quando o Git pedir credenciais, informe git como nome de usuário e um Personal Access Token como senha. Gere o token em Account Settings; ele é válido por um ano. A senha da sua conta não funciona.

As alterações não são sincronizadas automaticamente: use git pull para obter as alterações feitas no editor e git push para enviar as suas. O caminho /git é servido pelo contêiner sharelatex, então um proxy reverso na frente dele não precisa de nenhuma regra extra.

git push falha com HTTP 413 ou curl 55 Broken pipe

O push é maior que o limite de tamanho de upload, definido por MAX_UPLOAD_SIZE (em megabytes, 50 por padrão), que também se aplica a pushes. Aumente-o em config/variables.env, por exemplo MAX_UPLOAD_SIZE=200, e depois execute bin/up -d. Se você usa o proxy TLS ou seu próprio proxy reverso, aumente também o client_max_body_size dele (50M no config/nginx/nginx.conf do Toolkit).

O git-bridge também recusa arquivos maiores que 50 MB e projetos com mais de 2.000 arquivos. Esses limites são definidos por GIT_BRIDGE_REPOSTORE_MAX_FILE_SIZE (em bytes) e GIT_BRIDGE_REPOSTORE_MAX_FILE_NUM em config/variables.env.

O log do git-bridge mostra Failed to fetch log level

O aviso é inofensivo, e clone, pull e push continuam funcionando. Na versão 6.2.x, o git-bridge consulta o servidor de metadados do Google Cloud (metadata.google.internal) uma vez por minuto para obter um nível de log, o que só funciona no Google Cloud. Em outros ambientes, a solicitação falha, o git-bridge registra o erro (como null ou um status HTTP) e mantém o nível definido em GIT_BRIDGE_LOG_LEVEL. A partir da 6.3.0, essa verificação está desativada, e a atualização também atualiza a imagem do git-bridge, cuja versão acompanha a imagem principal.

Preciso do serviço track-changes ou de OVERLEAF_IS_SERVER_PRO=true para o Git e o histórico completo do projeto?

Resposta: Não. O Ayakaleaf Pro não tem um serviço track-changes. O histórico do projeto é mantido pelos serviços project-history e history-v1, que sempre são executados dentro do contêiner sharelatex. O git-bridge lê o histórico do history-v1 em V1_HISTORY_URL (http://sharelatex:3100/api), que o Toolkit define. Não defina OVERLEAF_IS_SERVER_PRO: nenhum recurso depende dela; ela apenas faz com que as migrações de banco de dados executadas na inicialização passem a ser as do conjunto do Server Pro.