Publicar a partir do CI

O caso mais comum: validar em todo pull request e publicar quando a branch principal muda. Assim o modelo nunca fica atrás do código, e ninguém precisa lembrar de publicar.

O que o CI precisa

Uma variável de ambiente, e mais nada:

CFOUR_KEY	a chave de publicação, guardada como segredo do seu CI

CFOUR_KEY vence o arquivo de credenciais, e é por isso que ela é a forma certa em CI — não há ninguém para rodar cfour login.

Sem terminal, a ferramenta nunca pergunta: todo campo tem uma opção, e a recusa diz qual falta.

GitHub Actions

.github/workflows/arquitetura.yml

name: arquitetura

on:
  push:
    branches: [main]
  pull_request:

jobs:
  arquitetura:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - run: npm install -g cfour-cli

      # Vale em todo push e em todo pull request. Sai com código 1 em erro.
      - run: cfour check --all

      # Só na branch principal.
      - if: github.ref == 'refs/heads/main'
        run: cfour push --no-input
        env:
          CFOUR_KEY: ${{ secrets.CFOUR_KEY }}

GitLab CI

.gitlab-ci.yml

arquitetura:
  image: node:20
  script:
    - npm install -g cfour-cli
    - cfour check --all
    - if [ "$CI_COMMIT_BRANCH" = "$CI_DEFAULT_BRANCH" ]; then cfour push --no-input; fi
  variables:
    CFOUR_KEY: $CFOUR_KEY

Publicar um preview em todo pull request

Um preview é qualquer ref que não seja a padrão do repositório. Ele expira sozinho em 30 dias, e qualquer membro pode publicá-lo — não é preciso ser admin.

      - if: github.event_name == 'pull_request'
        run: cfour push --ref "pr-${{ github.event.number }}" --no-input
        env:
          CFOUR_KEY: ${{ secrets.CFOUR_KEY }}

O link para ler aquele preview é o endereço do repositório com a ref como parâmetro de busca:

https://app.cfourdev.com.br/<organizacao>/<repositorio>/?ref=pr-42

Um repositório aceita 10 refs vivas ao mesmo tempo. Como o preview expira sozinho em 30 dias, isso só aperta num fluxo com mais de dez pull requests abertos por mês publicando diagramas — e aí vale publicar preview só quando o modelo mudou.

Detalhes que evitam surpresa

A ref vem do Git. Sem --ref, a ferramenta lê a branch atual. Um checkout em HEAD destacado — comum em CI — não tem branch, e a ferramenta recusa em vez de publicar sob um nome que não leva a lugar nenhum. Passe --ref explicitamente quando isso acontecer.

O commit também é carimbado. Sem --sha, ele vem do Git.

Ensaie antes. cfour push --dry-run compila, valida, diz o destino e não envia nada. Vale como passo de verificação num pull request.

A chave vence. Toda chave expira em 30, 90 ou 365 dias, escolhidos na criação. O cfour push imprime um aviso nos 14 dias anteriores ao vencimento, no log da execução — que é onde alguém já olha quando um job falha. Esse é o único canal: a plataforma não envia e-mail.

Guarde a chave como segredo. Ela não deve ser versionada. O arquivo local que o cfour login escreve é para a sua máquina, não para o CI.

Validar sem publicar

Se você quer só a validação, cfour check --all basta — e nem precisa de chave. Esse é um bom primeiro passo: colocar o modelo sob CI antes de decidir publicar.