TMF/ci-shared
Watch
3
0
Fork
You've already forked ci-shared
 0
Code Pull requests Projects Releases Packages Wiki Activity Actions

fix(ci): verificar-docs-produto lê o token do TMF/ORG do Infisical, secret como fallback [INFRA-68379] #44

Merged
tarcisio merged 1 commit from fix/verificar-docs-token-infisical into develop 2026-10-05 06:40:07 -03:00
Conversation 1 Commits 1 Files changed 2 +146 -10
tmf-ia commented 2026-10-05 01:46:24 -03:00
Owner
Copy link

O que muda

verificar-docs-produto.yml passa a ler o token de leitura do TMF/ORG do Infisical (INFRA/prod/ci, segredo CVE_OS_EXCECOES_TOKEN: o mesmo token só-leitura da lista única de CVE, INFRA-68311), com o secret FORGEJO_TOKEN mantido como fallback até o HelpCor migrar. Antes o DANI (que não tem esse secret; DAIS-68002) ficava travado nesse job (#827).

  • Passo novo "Token do TMF/ORG (Infisical)": action infisical-secrets (já usada no release.yml), continue-on-error.
  • "Checkout do script (TMF/ORG)": clone por git puro em um passo só (padrão do security-trivy), o token não sai do passo. Ordem: Infisical → secret (com ::warning::) → sem nenhum, falha sem chamar o git.

Prova (vermelho → verde)

tests/ci-unico/test_verificar_docs_token.py (novo, 7 testes) executa o script do passo com um git falso: o Infisical vence o secret; só-secret cai no fallback com aviso; sem nenhum falha e não chama o git; o valor do token nunca aparece no log. Contra o workflow anterior: 7 falham. Depois: ci-unico 50 OK; ci-config, infisical-secrets, soberania, nginx-log, hub-issue-sync OK. (release roda no CI.)

Um achado do próprio teste, já corrigido: o echo "::add-mask::$TOKEN" imprimia o valor; removido (o secret já é mascarado pelo runner e o do Infisical pela action).

⚠️ Limites

  • O segredo CVE_OS_EXCECOES_TOKEN ainda não existe no Infisical (o operador vai criar o token). Até lá o job usa o fallback, e o DANI continua travado: este PR não destrava ninguém sozinho.
  • Não verifiquei que a identity do runner lê o projeto INFRA no ambiente prod, nem que INFRA é o slug aceito pelo workspaceSlug; só testei contra o Infisical falso. Se falhar, cai no fallback (e o log mostra o erro do passo).
  • Dois usos do mesmo token ampliam o raio se ele vazar. Escopo: só leitura do TMF/ORG.
  • O release.yml e outros chamam a action por @main; o reusable aponta @main também, então depende de a develop ir à main para valer nos produtos.
  • Base develop.

Refs: INFRA-68379, INFRA-68311, DAIS-68002.

🤖 Generated with Claude Code

https://claude.ai/code/session_01UdMSC8CGmShbesE5rfVNfe

## O que muda `verificar-docs-produto.yml` passa a ler o token de leitura do TMF/ORG do **Infisical** (`INFRA/prod/ci`, segredo `CVE_OS_EXCECOES_TOKEN`: o **mesmo** token só-leitura da lista única de CVE, INFRA-68311), com o secret `FORGEJO_TOKEN` mantido como **fallback** até o HelpCor migrar. Antes o DANI (que não tem esse secret; DAIS-68002) ficava travado nesse job (#827). - Passo novo "Token do TMF/ORG (Infisical)": action `infisical-secrets` (já usada no `release.yml`), `continue-on-error`. - "Checkout do script (TMF/ORG)": clone por **git puro em um passo só** (padrão do `security-trivy`), o token não sai do passo. Ordem: Infisical → secret (com `::warning::`) → sem nenhum, **falha sem chamar o git**. ## Prova (vermelho → verde) `tests/ci-unico/test_verificar_docs_token.py` (novo, 7 testes) executa o script do passo com um `git` falso: o Infisical vence o secret; só-secret cai no fallback com aviso; sem nenhum falha e **não chama o git**; o valor do token **nunca aparece no log**. Contra o workflow anterior: **7 falham**. Depois: `ci-unico` 50 OK; `ci-config`, `infisical-secrets`, `soberania`, `nginx-log`, `hub-issue-sync` OK. (`release` roda no CI.) Um achado do próprio teste, já corrigido: o `echo "::add-mask::$TOKEN"` imprimia o valor; removido (o secret já é mascarado pelo runner e o do Infisical pela action). ## ⚠️ Limites - **O segredo `CVE_OS_EXCECOES_TOKEN` ainda não existe** no Infisical (o operador vai criar o token). Até lá o job usa o fallback, e o **DANI continua travado**: este PR não destrava ninguém sozinho. - **Não verifiquei** que a identity do runner lê o projeto `INFRA` no ambiente `prod`, nem que `INFRA` é o slug aceito pelo `workspaceSlug`; só testei contra o Infisical falso. Se falhar, cai no fallback (e o log mostra o erro do passo). - Dois usos do mesmo token ampliam o raio se ele vazar. Escopo: só leitura do TMF/ORG. - O `release.yml` e outros chamam a action por `@main`; o reusable aponta `@main` também, então depende de a `develop` ir à `main` para valer nos produtos. - Base `develop`. Refs: INFRA-68379, INFRA-68311, DAIS-68002. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01UdMSC8CGmShbesE5rfVNfe
fix(ci): verificar-docs-produto lê o token do TMF/ORG do Infisical, secret como fallback [INFRA-68379]
All checks were successful
PR checks (ci-shared) / testes (pull_request) Successful in 2m27s
Details
d0410bb51e 
O reusable clonava o ORG com secrets.FORGEJO_TOKEN, que o DANI não tem (DAIS-68002:
workflows leem do Infisical). Agora lê CVE_OS_EXCECOES_TOKEN (INFRA/prod/ci, o mesmo
token só-leitura da lista única de CVE, INFRA-68311), com continue-on-error, e clona
por git dentro de um passo: Infisical vence, FORGEJO_TOKEN é fallback com aviso, sem
nenhum dos dois falha sem chamar o git; o valor nunca vai ao log.

Teste executa o script do passo com git falso: 7 vermelhos contra o workflow anterior,
verdes depois (tests/ci-unico 50 OK; ci-config, infisical-secrets, soberania OK).

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UdMSC8CGmShbesE5rfVNfe
tarcisio merged commit e0a7f1be0f into develop 2026-10-05 06:40:07 -03:00
tarcisio deleted branch fix/verificar-docs-token-infisical 2026-10-05 06:40:07 -03:00
tarcisio commented 2026-10-05 07:05:09 -03:00
Owner
Copy link

DESCRIÇÃO ATUALIZADA — substitui a do corpo do PR (a CLI não edita o corpo).

Causa real (achada pela sessão ORG)

O verificar-docs nunca passou em produto algum: o Forgejo recusa secret com prefixo FORGEJO_ (reservado). Então secrets.FORGEJO_TOKEN no reusable era o token automático do job, que só enxerga o próprio repo, e o clone do TMF/ORG dava "target couldn't be found". Nenhum produto poderia ter esse secret.

O que muda

verificar-docs-produto.yml recebe o token de leitura do TMF/ORG, nesta ordem:

  1. input org_leitura_token: o caller passa with: org_leitura_token: ${{ secrets.ORG_LEITURA_TOKEN }};
  2. secrets.ORG_LEITURA_TOKEN de caller que usa secrets:;
  3. Infisical INFRA/prod/ci, CVE_OS_EXCECOES_TOKEN (o mesmo token só-leitura da lista única de CVE; passo continue-on-error, só roda se o input não veio);
  4. nenhum: falha com mensagem clara, sem chamar o git.

FORGEJO_TOKEN saiu da cadeia (o log do erro explica por quê). Clone por git puro dentro de um passo só; o token não vira output nem é impresso.

⚠️ Desvio da proposta, com motivo

A proposta era declarar ORG_LEITURA_TOKEN em on.workflow_call.secrets. Não declarei: o repo inteiro documenta e testa que o bloco secrets: em workflow_call faz o Forgejo rejeitar o arquivo ("Failing after 0s", INFRA-64944; tests/ci-unico/test_ci.py trava isso no ci.yml). Segui o padrão do hub-issue-sync (input + secrets.X de caller legado, sem declaração). O caller que prefere secrets: ORG_LEITURA_TOKEN: ... também funciona (caminho 2); o do input é o mais seguro.

Prova

tests/ci-unico/test_verificar_docs_token.py (8 testes + trava): git falso, ordem input > secret > cofre, falha sem token sem chamar o git, valor nunca no log, sem bloco secrets:, sem FORGEJO_TOKEN. Contra a versão anterior do PR: 6 falham. Depois: ci-unico 52 OK; ci-config, infisical-secrets, soberania OK.

Erro meu pego na revisão: a mensagem de erro tinha ${{ secrets.ORG_LEITURA_TOKEN }} dentro do run:, que o runner avaliaria antes do shell (injetaria o valor). Removido e travado por teste (a trava foi escrita depois da correção; não a vi vermelha).

⚠️ Limites

  • Só testei contra git falso. Não rodei o reusable num runner real: o input recebendo ${{ secrets.X }} e o secrets.ORG_LEITURA_TOKEN não declarado seguem o precedente do hub-issue-sync, mas não os vi funcionar neste reusable.
  • Não destrava ninguém sozinho: o operador precisa cadastrar ORG_LEITURA_TOKEN em DANI e helpcor-admin, e os callers (verificar-docs.yml do DANI #827 e do HelpCor) precisam passar o input. O reusable é chamado por @main: vale só depois do release develop→main do ci-shared (só do operador).
  • O passo do Infisical não foi verificado contra a identity real dos runners (INFRA/prod).
  • Base develop.

Refs: INFRA-68379, INFRA-68311, DAIS-68002.

🤖 Generated with Claude Code

https://claude.ai/code/session_01UdMSC8CGmShbesE5rfVNfe

**DESCRIÇÃO ATUALIZADA — substitui a do corpo do PR (a CLI não edita o corpo).** ## Causa real (achada pela sessão ORG) O verificar-docs **nunca passou em produto algum**: o Forgejo recusa secret com prefixo `FORGEJO_` (reservado). Então `secrets.FORGEJO_TOKEN` no reusable era o **token automático do job**, que só enxerga o próprio repo, e o clone do TMF/ORG dava "target couldn't be found". Nenhum produto poderia ter esse secret. ## O que muda `verificar-docs-produto.yml` recebe o token de leitura do TMF/ORG, nesta ordem: 1. **input `org_leitura_token`**: o caller passa `with: org_leitura_token: ${{ secrets.ORG_LEITURA_TOKEN }}`; 2. **`secrets.ORG_LEITURA_TOKEN`** de caller que usa `secrets:`; 3. **Infisical** `INFRA/prod/ci`, `CVE_OS_EXCECOES_TOKEN` (o mesmo token só-leitura da lista única de CVE; passo `continue-on-error`, só roda se o input não veio); 4. nenhum: **falha com mensagem clara, sem chamar o git**. `FORGEJO_TOKEN` saiu da cadeia (o log do erro explica por quê). Clone por git puro dentro de um passo só; o token não vira output nem é impresso. ### ⚠️ Desvio da proposta, com motivo A proposta era declarar `ORG_LEITURA_TOKEN` em `on.workflow_call.secrets`. **Não declarei**: o repo inteiro documenta e testa que o bloco `secrets:` em `workflow_call` faz o Forgejo **rejeitar o arquivo** ("Failing after 0s", INFRA-64944; `tests/ci-unico/test_ci.py` trava isso no `ci.yml`). Segui o padrão do `hub-issue-sync` (input + `secrets.X` de caller legado, sem declaração). O caller que prefere `secrets: ORG_LEITURA_TOKEN: ...` também funciona (caminho 2); o do input é o mais seguro. ## Prova `tests/ci-unico/test_verificar_docs_token.py` (8 testes + trava): `git` falso, ordem input > secret > cofre, falha sem token sem chamar o git, valor nunca no log, sem bloco `secrets:`, sem `FORGEJO_TOKEN`. Contra a versão anterior do PR: **6 falham**. Depois: `ci-unico` 52 OK; `ci-config`, `infisical-secrets`, `soberania` OK. Erro meu pego na revisão: a mensagem de erro tinha `${{ secrets.ORG_LEITURA_TOKEN }}` dentro do `run:`, que o runner avaliaria antes do shell (injetaria o valor). Removido e travado por teste (a trava foi escrita depois da correção; não a vi vermelha). ## ⚠️ Limites - **Só testei contra `git` falso.** Não rodei o reusable num runner real: o input recebendo `${{ secrets.X }}` e o `secrets.ORG_LEITURA_TOKEN` não declarado seguem o precedente do `hub-issue-sync`, mas não os vi funcionar **neste** reusable. - **Não destrava ninguém sozinho:** o operador precisa cadastrar `ORG_LEITURA_TOKEN` em DANI e helpcor-admin, e os **callers** (`verificar-docs.yml` do DANI #827 e do HelpCor) precisam passar o input. O reusable é chamado por `@main`: **vale só depois do release `develop`→`main` do ci-shared** (só do operador). - O passo do Infisical não foi verificado contra a identity real dos runners (INFRA/prod). - Base `develop`. Refs: INFRA-68379, INFRA-68311, DAIS-68002. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01UdMSC8CGmShbesE5rfVNfe
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
  
seguranca
Segurança/LGPD — merge só com aprovação do operador

No labels
seguranca
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
TMF/ci-shared!44
No description provided.