Posso usar o gitlab para monitorar repos existentes, mantendo antigos URLs git?

Question

Eu instalei o Gitlab no meu servidor e não sei se o que estou disposto a fazer é possível.

Eu quero configurar o Gitlab para monitorar meus repositórios, com todos os produtos que vêm com ele, mas não quero usar URLs do gitlab, já que não quero forçar uma dor no pescoço por todo o processo. devs usando os repos.

O recurso "Importar" do próprio Gitlab parece criar seus próprios URLs, de modo que não seria o que estou procurando.

Minha pergunta é: existe uma maneira de usar o gitlab com as antigas URLs git nuas?

    

Answer 1

Minha resposta curta é "Não".

Não é um problema tão grande alterar ou adicionar um novo controle remoto a um repositório existente. Basta fazer git remote add gitlab git@<server>/owner/repository_link.git (ou qualquer que seja o link) no projeto e pronto. Se você quiser substituir o controle remoto "origem", poderá ver o que fazer, mesmo manualmente, na pasta .git . Então, eu não estaria tão preocupado com as novas URLs, simplesmente documentaria o que precisa ser feito e as notificaria que você se mudou.

    

Answer 2

Infelizmente, o gitlab confia em seu esquema de URL para obter suas permissões de grupo / usuário por repo.

A única maneira que posso imaginar é que é possível usar regras de reconfiguração personalizadas no servidor da Web de front-end. Essas regras, então, reescreveriam todas as solicitações apropriadamente para o esquema de nomenclatura gitlab. Isso, é claro, exigiria que seus desenvolvedores usassem apenas http (s) para acessar os repositórios. Essa abordagem não quebraria seu código da base de código upstream.

No entanto, se você estava usando ssh: // também (o que é recomendado pelo git), a única maneira que eu vejo é que você faça uma reescrita do caminho no gitlab-shell: A classe GitlabShell tem este método parse_cmd

def parse_cmd
  args = Shellwords.shellwords(@origin_cmd)
  @git_cmd = args[0]
  @repo_name = escape_path(args[1])
end

em que você poderia mexer com @repo_name. Essa abordagem quebraria seu código da base de código upstream.

Sinto muito, mas como você não especificou nenhum exemplo de repositório, é difícil criar um exemplo mais concreto.

Pessoalmente, eu iria com a migração para importar os repositórios e publicar os novos URLs. Se você puder fornecer uma lista de git remote set-url origin ssh://[email protected]/newgroup/imported.git para seus colegas, isso minimizaria o trabalho do lado deles, eu acho.