Este recurso foi desenvolvido por ayaka-notes/ayakaleaf-pro. Ele foi introduzido na v6.4.0 e posteriores. Ainda está em fase beta. Precisamos do seu feedback caso encontre algum problema.
Configurar a sincronização com GitLab
Crie um aplicativo OAuth na sua instância do GitLab, em User settings → Applications (ou Admin area → Applications para um aplicativo de toda a instância):- Redirect URI:
${OVERLEAF_SITE_URL}/user/gitlab-sync/oauth2/callback - Confidential: marcado
- Scopes:
api
config/variables.env
GitLab autogerenciado
DefinaGITLAB_SYNC_URL como o endereço web da sua instância, aquele com o qual você abre os projetos no navegador. A API REST é derivada dele:
Defina
GITLAB_SYNC_API_URL apenas quando a sua instância disponibilizar a API em outro lugar, por exemplo, atrás de um gateway de API.
Se a sua instância usar um certificado de uma CA privada, monte o certificado da CA no contêiner e aponte
NODE_EXTRA_CA_CERTS para ele, por exemplo, NODE_EXTRA_CA_CERTS=/var/lib/overleaf/certs/gitlab-ca.pem.Contas e projetos vinculados pertencem à instância com a qual foram vinculados. Antes de mudar
GITLAB_SYNC_URL para outra instância, peça aos usuários que desvinculem sua conta do GitLab e seus projetos.GITLAB_SYNC_PROXY_URL=http://10.0.0.1:10808. Ele deve ser um proxy de encaminhamento HTTP/HTTPS padrão e não deve usar 127.0.0.1.
Quem pode vincular e sincronizar
Assim como no Overleaf Cloud, apenas o proprietário do projeto pode vincular um projeto a um repositório do GitLab. Depois de vinculado, todos os colaboradores com acesso de edição podem sincronizá-lo.- O Overleaf se comunica com o GitLab usando a conta do GitLab do usuário que sincroniza; portanto, cada colaborador que sincroniza vincula sua própria conta do GitLab e precisa ter permissão para fazer push no branch padrão do repositório.
- Colaboradores somente leitura não podem usar a sincronização com GitLab no projeto.
Como a sincronização funciona com o GitLab
- Permissões: os usuários precisam ter permissão para fazer push no branch padrão do projeto vinculado. Quando o branch padrão está protegido e o usuário não pode fazer push nele, o Overleaf pede que ele entre em contato com o proprietário do projeto, como acontece com um repositório ao qual ele perdeu o acesso.
- Merge: quando um projeto foi alterado tanto no Overleaf quanto no GitLab, o Overleaf faz commit de suas alterações em um branch temporário chamado
overleaf-YYYY-MM-DD-HHMMSSe o mescla por meio de um merge request, porque o GitLab não tem uma API para mesclar branches sem um. Após o merge, o Overleaf exclui o branch temporário e o merge request. Somente administradores e proprietários de projetos podem excluir merge requests no GitLab; portanto, para outros usuários, o merge request mesclado permanece no projeto. - Regras de merge: o Overleaf nunca contorna as regras de merge do projeto. Quando o merge request tem um conflito, ou precisa de uma aprovação ou de um pipeline bem-sucedido, ele permanece aberto e o Overleaf pede ao usuário que o mescle no GitLab e, em seguida, continue a sincronização.
- Pipelines: commits do Overleaf iniciam pipelines como qualquer outro commit. Se o seu projeto executa pipelines para merge requests e exige que eles sejam bem-sucedidos, os merges do Overleaf aguardam por eles, conforme descrito acima.
Q&A
Posso fazer force push no branch padrão?
Posso fazer force push no branch padrão?
Resposta: Mantenha os force pushes no branch padrão desativados. Esse é o padrão do GitLab: o branch padrão de um novo projeto é protegido e ninguém pode fazer force push nele. O Overleaf consegue assumir um branch reescrito, mas a sincronização com GitLab foi projetada para um branch padrão cujo histórico apenas cresce.
Posso renomear o branch padrão de um projeto vinculado?
Posso renomear o branch padrão de um projeto vinculado?
Resposta: Não. O Overleaf continua sincronizando com o branch ao qual o projeto foi vinculado, portanto as sincronizações falham quando esse branch é renomeado ou removido. Para sincronizar com outro branch, desvincule o projeto e, em seguida, importe o repositório para um novo projeto, que usará o branch padrão atual.

