# Forgejo CI/CD

`.forgejo/workflows/pipeline.yml` runs verification for pushes and pull
requests. A push to `main` also publishes immutable commit-SHA tags for the API,
load generator, and web images, then deploys the API and load generator through
the production overlay and Argo Rollouts.

Two load-generator Deployments keep traffic on both the active and preview
Services. Preview traffic is required for the pre-promotion analysis to measure
the candidate revision instead of treating absent samples as success.

The repository needs a dedicated Forgejo runner labelled `docker`. It must have
Docker with Compose support, outbound access to the configured registries, and
network access to the Kubernetes API endpoint contained in the kubeconfig.
Keep this runner private to trusted repositories because deployment jobs can
access the Docker socket and production credentials.

Configure these encrypted repository or organization Actions secrets in the
Forgejo UI:

- `REGISTRY_USERNAME`: account allowed to push the three Nereus packages.
- `REGISTRY_PASSWORD`: package-scoped token for that account.
- `KUBECONFIG_B64`: base64 encoding of a least-privilege deployment kubeconfig.
- `MIRROR_SSH_KEY`: private half of a write-enabled deploy key for
  `git@github.com:Fi3w0/Nereus.git`.

After registering that deploy key, every successful production deployment
pushes `main` to GitHub automatically. An absent or invalid mirror credential
fails only the final mirror job, after production has already deployed.

Before the first sealed deployment, a cluster administrator must bootstrap the
deployer's namespaced SealedSecret permission:

```bash
kubectl apply -k deploy/rbac
```

The deployer cannot grant this Role to itself. The Role permits only management
and waiting on `bitnami.com/sealedsecrets` in `nereus`; the controller remains
the only identity allowed to create the decrypted Secret.

The workflow never prints these values. It writes the kubeconfig to the
ephemeral workspace with mode `0600`, removes it in an `always()` step, and
creates the Kubernetes registry pull secret through a pipe so its generated
manifest is not logged or committed. The deploy job applies the committed
database SealedSecret and waits for the controller to synchronize it before
starting the application rollout. After a successful production deployment,
the mirror job pushes `main` to GitHub over SSH and removes its temporary key in
an `always()` step.