knowledge-base/records/infrastructure/KB-INFRA-003-git-dual-push-forgejo-lab-mindtek.md

5.4 KiB

id title domain tags status severity created_at updated_at applies_to related_records
KB-INFRA-003 Git dual-push para Forgejo lab + mindtek-dev (sem prompt de credenciais) infrastructure
git
forgejo
dual-push
credentials
sync
active medium 2026-06-29 2026-06-29
knowledge-base
any-git-repo-needing-mirror
KB-INFRA-001

Git dual-push para Forgejo lab + mindtek-dev (sem prompt de credenciais)

Contexto

Os repositórios do GLPI11 vivem em dois Forgejos paralelos:

Forgejo URL Acesso Uso
lab git@192.168.100.101:administrador/<repo>.git (SSH) Rede local CT100 Desenvolvimento individual
mindtek-dev https://onmind.mindtek.com.br/git/rodolpho.lopes/<repo> (HTTPS) Externo, sem VPN Equipe da Mindtek tem visibilidade

Trabalho local é feito no CT100 → push tem que replicar automaticamente para mindtek pra equipe ter a mesma visão, sem comandos extras.

SSH no mindtek-dev requer VPN — descartado. Solução: HTTPS com token salvo.

Padrão: um git push empurra pros 2 destinos

Configuração (uma vez por repo)

# 1. Credential helper global (uma vez por máquina)
git config --global credential.helper store

# 2. Salva o token HTTPS em ~/.git-credentials (uma vez por host)
echo "https://<user>:<TOKEN>@onmind.mindtek.com.br" >> ~/.git-credentials
chmod 600 ~/.git-credentials

# 3. Configura origin com 2 URLs de push (por repo)
cd /caminho/do/repo
git remote set-url --add --push origin "git@192.168.100.101:administrador/<repo>.git"
git remote set-url --add --push origin "https://onmind.mindtek.com.br/git/rodolpho.lopes/<repo>.git"

Resultado esperado

$ git remote -v
origin  git@192.168.100.101:administrador/<repo>.git (fetch)
origin  git@192.168.100.101:administrador/<repo>.git (push)
origin  https://onmind.mindtek.com.br/git/rodolpho.lopes/<repo>.git (push)

Uso diário

git add ...
git commit -m "..."
git push                # ← empurra pros DOIS forgejos sequencialmente

git pull / git fetch lê apenas do lab (mais rápido na CT100). Mudanças vindas da equipe pelo mindtek-dev precisam de fetch manual:

git fetch https://onmind.mindtek.com.br/git/rodolpho.lopes/<repo>.git main

Mas como o workflow é "trabalho local → push pra ambos", o lab sempre tem a versão mais recente; mindtek é só espelho.

Criar um repo novo no mindtek-dev (via API)

TOKEN="..."
curl -s -X POST -H "Authorization: token $TOKEN" -H "Content-Type: application/json" \
  "https://onmind.mindtek.com.br/git/api/v1/user/repos" \
  -d '{
    "name": "<repo>",
    "description": "...",
    "private": false,
    "auto_init": false,
    "default_branch": "main"
  }'

Resposta inclui clone_url (HTTPS) e ssh_url.

Gotchas

1. --add --push mantém ordem importante

Se você esquecer de adicionar o URL do lab como push (só rodar --add --push com mindtek), git considera que o pushurl é apenas o mindtek — push pra lab não acontece mesmo sendo o fetch URL.

Regra: sempre adicione AMBOS explicitamente com --add --push, mesmo o que já é fetch URL.

2. Falha em uma URL não para a outra

Git tenta os pushURLs em sequência. Se a 1ª falhar (ex: lab caiu), git continua pra 2ª. Mas o exit code do git push reflete a soma — falha em qualquer um retorna erro.

Pra investigar: olha o output do git push que mostra cada destino separadamente.

3. ~/.git-credentials é texto plano

Tem permissão 600 (só o owner lê), mas em backup/snapshot do disco vaza. Em ambientes com múltiplos usuários, prefira credential.helper cache --timeout=3600 (memória, não disco).

4. Token expirou? Não dá erro óbvio

Push HTTPS falha com mensagem de "fatal: Authentication failed". Resolva editando ~/.git-credentials:

sed -i 's|:OLD_TOKEN@|:NEW_TOKEN@|' ~/.git-credentials

Ou apague a linha do host e o git pede o novo token no próximo push (e salva).

5. Token comprometido — como revogar

  1. https://onmind.mindtek.com.br/git/user/settings/applications → revoga
  2. Apaga a linha do host no ~/.git-credentials
  3. Cria novo token e re-adiciona

Replicar config em outro repo

Como credential.helper=store é global, qualquer repo que aponte pra onmind.mindtek.com.br herda o token sem reconfigurar. Pra adicionar dual-push:

cd /caminho/outro/repo
git remote set-url --add --push origin <URL_LAB>
git remote set-url --add --push origin <URL_MINDTEK>

Ou crie um alias de shell se for fazer várias vezes:

alias git-dualpush='_f() {
  git remote set-url --add --push origin "git@192.168.100.101:administrador/$1.git"
  git remote set-url --add --push origin "https://onmind.mindtek.com.br/git/rodolpho.lopes/$1.git"
}; _f'

# Uso:
git-dualpush knowledge-base

Aplicado em

  • /opt/projects/GLPI11/knowledge-base (validado em 2026-06-29)

Lições

  1. Múltiplos pushURLs no mesmo remote > múltiplos remotes separados — não precisa lembrar de git push lab && git push mindtek.
  2. Credential helper store é o caminho mais simples pra HTTPS sem prompt, desde que o ~/.git-credentials esteja com perms 600 e não vá pra backup público.
  3. Fetch fica num único destino — espelhamento via push é unidirecional. Pra puxar mudanças do mirror, fetch manual da URL.
  4. Token no URL embutido funciona mas vaza em git remote -v — sempre prefira credential helper a https://user:pass@host/....