Trunks de marca (branches paralelas)
O front-web-base não tem uma única branch principal. Ele opera com várias
branches de longa duração em paralelo — os trunks — cada uma servindo um
conjunto próprio de ambientes de produção. Features não são mergeadas de uma
trunk pra outra: são portadas.
Esta página existe porque esse modelo condiciona a leitura de todas as outras páginas de arquitetura. Leia antes de assumir que um comportamento descrito aqui vale pra branch em que você está.
:::warning Estas docs descrevem a main-7k
A linha tomada como referência nesta documentação é a main-7k. Ela é a
trunk com mais movimento e onde as mudanças arquiteturais recentes landaram
primeiro.
Se você está numa outra trunk (main, main-b, main-donald, …), parte do
que está documentado aqui pode não existir no seu código — a feature pode
não ter sido portada ainda. origin/main e origin/main-7k divergem hoje em
1.515 arquivos; origin/main e origin/main-b, em 1.494. Confira
sempre no seu working tree antes de assumir.
:::
Por que trunks e não branches de feature
O modelo é consequência de o repositório servir marcas com escopos regulatórios, contratos de sportsbook e roadmaps de produto diferentes. Uma trunk é o corte estável de um desses grupos: ela só recebe o que aquele grupo de marcas precisa, no ritmo daquele grupo.
O custo é o esperado: uma feature que precisa existir em duas trunks é
implementada, mergeada numa, e depois re-aplicada na outra. O histórico
registra isso explicitamente — a PR #1017 se chama
"feat(register): SMS-OTP phone validation step (port of #566 onto main-b)".
Também há PRs de sincronização em lote, como a #1873
(chore/sync-main-7k-into-main-b).
Consequências práticas:
- Corrigir um bug numa trunk não corrige nas outras. Um fix precisa de uma decisão explícita sobre quais trunks recebem o port.
git logde uma trunk não é o histórico do produto. Um commit pode existir com SHA diferente em cada trunk.- Não abra PR cross-trunk por reflexo. O merge direto entre trunks arrasta configuração de marca que não pertence ao destino.
As trunks hoje
Verifique a lista viva com:
cd repos/front-web-base
git for-each-ref --format='%(refname:short) %(committerdate:short)' refs/remotes/origin \
| grep -E '^origin/(main|stage|sports)'
As trunks que hoje têm ambiente de deploy apontado pra elas
(default_branch em front-ops):
| Trunk | Ambientes servidos |
|---|---|
main | state77-com, ph-state77-com, pt-state77-com, rj-bet, x2b-bet |
main-7k | prod-7k-bet-br, betpontobet-bet-br, bet7k-cl + 2 stages — linha de referência destas docs |
main-b | bet7k-ng, ng-7k-bet, fi-7k-bet, pb-bet |
main-donald | donald-bet-br |
main-cl-bet7k-com | cl-bet7k-com |
main-app | app-7k-bet-br-cactusgaming-tech |
main-7wins | 7wins-cc |
stage | react-casateste-com + stages de donald / fi / ng |
stage-7wins, stage-spa-v2, stage-workers-cache | Stages de experimento |
sports | 3 ambientes sportsbook-only (7k, betpontobet, cl.bet7k.com) |
refs/remotes/origin tem centenas de refs (835 na última contagem, a maioria
branches de feature vivas ou já mergeadas). Só as que aparecem como
default_branch de algum ambiente do front-ops são trunks de fato; o resto é
branch de trabalho. Há também trunks históricas mantidas por segurança
(main-7k-revert, main-bkp-14-05, main-fix-bk, …) que não recebem deploy.
Topologia de deploy
O ci-deploy.yml do front-web-base dispara em globs de branch, não em
nomes fixos:
# .github/workflows/ci-deploy.yml
branches: ['main', 'main-*', 'stage', 'stage-*', 'sports', 'sports-*']
Cada ambiente é um diretório em
front-ops/config/brands/<repo>/environments/<env>/deploy.yml, e é o campo
default_branch de lá que amarra o ambiente à trunk. Hoje:
- 28 ambientes em
config/brands/web-base/(repofront-web-base)
Total de 28 ambientes de marca. Para a lista atual:
ls repos/front-ops/config/brands/web-base/environments/
Um mesmo domínio pode ter vários ambientes apontando pra trunks diferentes —
cl.bet7k.com aparece em quatro (bet7k-cl em main-7k, cl-bet7k-com em
main-cl-bet7k-com, o stage em stage-spa-v2 e o sports-only em sports).
CACHE_NAMESPACE é o que mantém os caches desses workers isolados — ver
Cache architecture.
O lint que segura a topologia
O job config-lint do ci-deploy.yml valida que todo default_branch
declarado no front-ops casa com pelo menos um glob de
on.push.branches / on.pull_request.branches. Criar uma trunk com um prefixo
novo sem adicionar o glob correspondente falha o CI com
does not cover these ops branches.
Ou seja: a trunk nova só passa a existir de verdade depois de duas mudanças —
o ambiente no front-ops e o glob no ci-deploy.yml.
auto_deploy
Cada deploy.yml traz auto_deploy: true|false. Com false, o push na trunk
não publica — o deploy é workflow_dispatch manual. Hoje é o caso de quatro
ambientes de produção (prod-7k-bet-br, bet7k-cl, betpontobet-bet-br,
cl-bet7k-com).
Separadamente, um ambiente pode declarar deploy_protection.required_team —
restringe quem pode disparar o workflow_dispatch daquele ambiente. Os dois campos
são independentes: 15 dos 28 ambientes de web-base declaram required_team,
inclusive vários com auto_deploy: true. Push (auto-deploy) nunca é gateado por
esse campo — ele só vale pro dispatch manual.
Trunks × marcas × forks — três eixos distintos
Não confunda os três:
| Eixo | Mecanismo | Onde vive |
|---|---|---|
| Trunk | branch de longa duração | origin/main*, origin/stage*, origin/sports* |
| Marca | diretório de override resolvido em build time | overrides/<brand-key>/ no front-web-base |
| Fork | repositório separado | nenhum ativo hoje |
Uma trunk carrega todas as marcas do repositório — o que seleciona a marca
em runtime é o ORIGIN_DOMAIN do worker, resolvido pelo
brandOverridesPlugin. Ver Multi-tenancy e
override-files.
Não há fork ativo do front-web-base. As marcas cassino-bet-br e
vera-bet-br foram removidas do base em 2026-07-28 e não têm mais override nem
ambiente de deploy — qualquer doc, exemplo ou config que ainda mencione essas
duas marcas como ativas está desatualizado.
Ao trabalhar numa mudança
- Descubra sua trunk antes de tudo:
git rev-parse --abbrev-ref HEADe compare com a tabela acima. - Decida o alcance no início, não no fim. "Isto vai pra quais trunks?" é pergunta de planejamento — descobrir depois do merge significa port manual com conflito.
- Ao portar, re-verifique as premissas no destino. O arquivo que você editou pode ter outro conteúdo, outro nome ou não existir na trunk destino.
- Config de marca não viaja. Um port deve levar a mudança de comportamento, não os overrides da marca de origem.