CI/CD — GitHub Actions

Todos os repositórios da org cactus-agents usam GitHub Actions para CI e deploy.

Workflows por repositório

front-cactus-core (SDK)

Workflow	Trigger	O que faz
ci.yml	Push em main, PRs	Lint → Check → Build → Test
release.yml	Push em main (com changesets pendentes)	Build → Changesets (cria PR ou publica)

front-web-base (Template) e forks

Workflow	Trigger	O que faz
quality.yml	Push em main, PRs	Lint → Check → Typecheck → Test
deploy.yml	Push em main, tags v*	Build → Deploy (Cloudflare Workers)

Changesets (front-cactus-core)

O monorepo SDK usa @changesets/cli para versionamento e publicação automática dos pacotes @cactus-agents/*.

Fluxo

1. Dev cria changeset local:     pnpm changeset
2. Push em main com changeset → Actions cria PR "chore: version packages"
3. Merge do PR               → Actions publica no GitHub Packages

Criando um changeset

cd front-cactus-core
pnpm changeset
# Selecionar pacotes alterados
# Escolher bump type (patch / minor / major)
# Escrever descrição da mudança

O changeset é um arquivo .md em .changeset/ que deve ser commitado junto com a alteração.

Publicação

O workflow release.yml usa changesets/action@v1:

• Se existem changesets pendentes → cria/atualiza o PR "chore: version packages"
• Se o PR for mergeado (sem changesets pendentes) → executa pnpm run release que builda e publica

A publicação usa NODE_AUTH_TOKEN com GITHUB_TOKEN do próprio repositório (o core publica pacotes no seu próprio escopo, então o token padrão funciona).

Secrets

Org-level secrets (compartilhados por todos os repos)

Secret	Escopo	Uso
GH_PACKAGES_TOKEN	read:packages	Instalar @cactus-agents/* no CI dos repos consumidores

Per-repo secrets (específicos de cada fork)

Secret	Repo	Uso
CLOUDFLARE_API_TOKEN	front-web-base e forks	Deploy no Cloudflare Workers
CLOUDFLARE_ACCOUNT_ID	front-web-base e forks	Identificar a conta Cloudflare

Permissões dos workflows

Os workflows devem declarar o bloco permissions explicitamente:

jobs:
  quality:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: read

Sem esse bloco, o GITHUB_TOKEN recebe permissões padrão que podem não incluir packages: read.

Adicionando CI/CD a um novo fork

Ao criar um fork de front-web-base, os workflows já vêm incluídos. Basta:

1. Configurar os secrets CLOUDFLARE_API_TOKEN e CLOUDFLARE_ACCOUNT_ID no repo do fork
2. O GH_PACKAGES_TOKEN já está disponível via org secret
3. Push em main → workflows rodam automaticamente