feat: adding multi-arch image builds and kubectl manifest deployment

AGENTS.md

@@ -20,6 +20,7 @@ Logs into the container registry, sets up SSH key for `docker-build.haven`, crea
 - `platforms` (default `linux/amd64,linux/arm64`) — target build platforms
 - `build_context` (default `.`) — Docker build context path
 - `build_dockerfile` (default `Dockerfile`) — Dockerfile path relative to context
+- `build_args` (default empty) — build arguments, one `KEY=VALUE` per line; each becomes a `--build-arg`
 - `docker_host` (default `docker-build.haven`) — remote builder hostname
 - `docker_user` (default `root`) — SSH user for remote builder
 
@@ -33,6 +34,19 @@ Validates `KUBE_CONFIG`, installs kubectl, and performs `rollout restart` of a K
 - `namespace` (default `default`) — Kubernetes namespace
 - `kube_version` (default `stable`) — kubectl version to download
 
+### `kubectl-apply` (`kubectl-apply/action.yaml`)
+
+Validates `KUBE_CONFIG`, installs kubectl, and applies Kubernetes manifest(s) that live inside the repository. This is the in-repo, k8s analog of `ssh-deploy`'s `compose_files`, and the recommended way to deploy manifest specs committed to the consuming repo. Pair it with `deploy-restart` when a restart is also required (Deployments); use it alone for CronJobs, Services, Ingresses, Secrets, etc.
+
+**Inputs:**
+- `kube_config` (required) — full kubeconfig YAML (use secrets)
+- `manifest` (default empty) — single manifest path (relative to repo root) to apply
+- `manifests` (default empty) — space-/comma-separated list of manifest paths; each applied with its own `kubectl apply -f`
+- `namespace` (default empty) — adds `-n <ns>` when non-empty (manifests may also self-declare their namespace)
+- `kube_version` (default `stable`) — kubectl version to download
+
+> At least one of `manifest`/`manifests` must be set. A path that does not exist in the repo fails the step — the manifest must be committed to the repo.
+
 ### `ssh-deploy` (`ssh-deploy/action.yaml`)
 
 SSH into a remote host, pull the latest images with `docker compose pull`, and recreate containers with `docker compose up -d --force-recreate`. Uses native `ssh`/`ssh-keyscan` — no third-party SSH action.
@@ -80,6 +94,12 @@ jobs:
     runs-on: ubuntu-amd64
     needs: build
     steps:
+      # Deployment specs live in the repo; apply them with kubectl-apply.
+      - uses: https://git.ivanch.me/ivanch/pipeline-actions/kubectl-apply@main
+        with:
+          kube_config: ${{ secrets.KUBE_CONFIG }}
+          manifest: deploy/<PROJECT_NAME>.yaml
+      # Restart the Deployment so the new image is rolled out.
       - uses: https://git.ivanch.me/ivanch/pipeline-actions/deploy-restart@main
         with:
           kube_config: ${{ secrets.KUBE_CONFIG }}
@@ -109,6 +129,7 @@ Consumer projects must set these secrets in Gitea repo settings (Settings → Ac
 - Always build `linux/amd64,linux/arm64` — the cluster has mixed arch (iris+vega=amd64, nebula+nexus=arm64).
 - Workflow files go in `.gitea/workflows/main.yaml` of the consuming project.
 - The consuming project must have a working `Dockerfile` at the repo root (or pass `build_dockerfile` input).
+- Kubernetes deploy specs are committed to the consuming repo (e.g. under `*/deploy/*.yaml`) and applied with `kubectl-apply`. Pass their repo-relative path via `manifest`/`manifests`. Do **not** write deploy specs inline in the workflow — they belong in the repo so they can be reviewed and versioned.
 
 ## Do Not