docs(KB-INFRA-003): documenta dual-push Git para Forgejo lab + mindtek-dev
This commit is contained in:
Rodolpho Lopes
parent
c6eed78378
commit
52b88983b4
2 changed files with 176 additions and 1 deletions
18
index.json
18
index.json
|
|
@ -1,6 +1,6 @@
|
|||
{
|
||||
"version": "1.0.0",
|
||||
"last_updated": "2026-06-22",
|
||||
"last_updated": "2026-06-29",
|
||||
"records": [
|
||||
{
|
||||
"id": "KB-INFRA-001",
|
||||
|
|
@ -35,6 +35,22 @@
|
|||
"path": "records/infrastructure/KB-INFRA-002-plugin-icon-logo-png.md",
|
||||
"summary": "id: KB-INFRA-002"
|
||||
},
|
||||
{
|
||||
"id": "KB-INFRA-003",
|
||||
"title": "Git dual-push para Forgejo lab + mindtek-dev (sem prompt de credenciais)",
|
||||
"domain": "infrastructure",
|
||||
"tags": [
|
||||
"git",
|
||||
"forgejo",
|
||||
"dual-push",
|
||||
"credentials",
|
||||
"sync"
|
||||
],
|
||||
"status": "active",
|
||||
"severity": "medium",
|
||||
"path": "records/infrastructure/KB-INFRA-003-git-dual-push-forgejo-lab-mindtek.md",
|
||||
"summary": "id: KB-INFRA-003"
|
||||
},
|
||||
{
|
||||
"id": "KB-PLUGIN-001",
|
||||
"title": "Instalacao de plugin GLPI requer callbacks install/uninstall",
|
||||
|
|
|
|||
|
|
@ -0,0 +1,159 @@
|
|||
---
|
||||
id: KB-INFRA-003
|
||||
title: Git dual-push para Forgejo lab + mindtek-dev (sem prompt de credenciais)
|
||||
domain: infrastructure
|
||||
tags:
|
||||
- git
|
||||
- forgejo
|
||||
- dual-push
|
||||
- credentials
|
||||
- sync
|
||||
status: active
|
||||
severity: medium
|
||||
created_at: 2026-06-29
|
||||
updated_at: 2026-06-29
|
||||
applies_to:
|
||||
- knowledge-base
|
||||
- any-git-repo-needing-mirror
|
||||
related_records:
|
||||
- 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)
|
||||
|
||||
```bash
|
||||
# 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
|
||||
|
||||
```bash
|
||||
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:
|
||||
```bash
|
||||
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)
|
||||
|
||||
```bash
|
||||
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`:
|
||||
```bash
|
||||
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:
|
||||
|
||||
```bash
|
||||
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:
|
||||
```bash
|
||||
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/...`.
|
||||
Loading…
Reference in a new issue