Files

T

thanhnvandClaude Opus 4.8 8c20cfde9f feat(packaging): level-based source hub — Core + DevKit packaging, Platform/Enterprise scaffold

Organize CASAN as a reusable source hub with SPLIT releases so downstream adopts only the
level it needs (packaging/levels.json is the single source of truth).

Implemented now:
- Level 1 Core: bin/casan CLI (run/gate/test/verify/reuse/dashboard) + VERSION.
- Level 2 DevKit: packages/casan-devkit (install.sh, Dockerfile.harness, templates:
  project scaffold, domain-pack, gitea-workflow).
- scripts/package-release.sh core|devkit|platform|all-in-one-demo — builds split bundles
  into dist/ (BUNDLE-MANIFEST + SHA256SUMS); platform is stamped PREVIEW/INCOMPLETE;
  enterprise (future) is REFUSED (exit 3, no fake-complete package). Bundles verified:
  extract → bin/casan works, deterministic + domain suites pass, casan reuse VALID.
- docs/packaging: CASAN_PACKAGING_PLAN + ADOPTION + CI + DOMAIN_PACK + GITEA_PACKAGE + DOCKER.

Structure + docs only:
- Level 3 packages/casan-platform (dashboard exists; control-panel/viewers pending).
- Level 4 packages/casan-enterprise (RBAC/tenant/KMS/WORM/approval exist in core; governed
  console pending). No Chat Console/RBAC-console/tenant-console/model-mgmt built in this task.

Harness change (enables extracted bundles to self-resolve): casan-paths.sh + the Python
project_root() walk-ups now accept a second root marker `packages/casan-harness` in addition
to `.specify`, so a freshly-unpacked core/devkit/demo bundle (no `.specify` yet) roots
correctly and creates state on first run. In an adopted repo `.specify` still matches first.
policy-bundle.yaml paths corrected to packages/casan-harness (re-signed). Full gate 64/0/3.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-07-08 15:55:37 +09:00

3.3 KiB

Raw Blame History

CASAN on Gitea — Source Hub + Package Registry

This repo uses the existing Gitea server (ssh://git@161.33.139.73:2222/admin/casan5.git) as the source hub. Gitea also ships a package registry (generic files) and a container registry, so CASAN release bundles and Docker images can live next to the source. This guide shows the release flow. No secrets are committed; use a Gitea token/PAT.

Gitea host below is written as $GITEA (e.g. http://161.33.139.73:3000). Set GITEA_TOKEN to a personal access token with write:package scope. Adjust admin/casan5 to your org/repo.

1. Build the bundles

scripts/package-release.sh core
scripts/package-release.sh devkit
scripts/package-release.sh platform          # preview
scripts/package-release.sh all-in-one-demo
# enterprise → intentionally refused (future)
ls dist/    # *.tar.gz + *.sha256

2. Publish tarballs to the Gitea generic package registry

Endpoint: PUT $GITEA/api/packages/{owner}/generic/{name}/{version}/{file}

GITEA=http://161.33.139.73:3000; OWNER=admin; V=$(cat VERSION)
for lvl in core devkit; do
  f="dist/casan-$lvl-v$V.tar.gz"
  curl -fsSL -XPUT -H "Authorization: token $GITEA_TOKEN" \
    --upload-file "$f" \
    "$GITEA/api/packages/$OWNER/generic/casan-$lvl/$V/$(basename "$f")"
  curl -fsSL -XPUT -H "Authorization: token $GITEA_TOKEN" \
    --upload-file "$f.sha256" \
    "$GITEA/api/packages/$OWNER/generic/casan-$lvl/$V/$(basename "$f").sha256"
done
# platform is a preview artifact:
curl -fsSL -XPUT -H "Authorization: token $GITEA_TOKEN" \
  --upload-file "dist/casan-platform-preview-v$V.tar.gz" \
  "$GITEA/api/packages/$OWNER/generic/casan-platform/$V-preview/casan-platform-preview-v$V.tar.gz"

Downstream then pulls:

curl -fsSL -H "Authorization: token $TOKEN" \
  "$GITEA/api/packages/admin/generic/casan-core/1.0.0/casan-core-v1.0.0.tar.gz" -o casan-core.tar.gz

3. Publish Docker images to the Gitea container registry

V=$(cat VERSION)
docker build -f packages/casan-devkit/Dockerfile.harness -t "$REG/admin/casan-harness:$V" .
echo "$GITEA_TOKEN" | docker login "$REG" -u admin --password-stdin   # REG=161.33.139.73:3000
docker push "$REG/admin/casan-harness:$V"

See DOCKER_GUIDE.md for image details. casan-platform:$V is preview; casan-enterprise:$V is future (do not publish).

4. Attach bundles to a Gitea Release (optional, human-facing)

Create a tag + release via the API and upload the tarballs as release attachments:

# create release for tag vX.Y.Z, then:
curl -fsSL -XPOST -H "Authorization: token $GITEA_TOKEN" \
  -F "attachment=@dist/casan-devkit-v$V.tar.gz" \
  "$GITEA/api/v1/repos/admin/casan5/releases/{release_id}/assets?name=casan-devkit-v$V.tar.gz"

5. Recommended cadence

Tag vX.Y.Z on main → CI green → build bundles → publish core + devkit (always), platform as -preview, all-in-one-demo for demos. Never publish enterprise.
Keep VERSION and packages/casan-harness/level5/harness-package.json version in lockstep.

Automating in CI

Add a release job to .gitea/workflows/ that runs after the gate, calls scripts/package-release.sh, and does the curl uploads with ${{ secrets.GITEA_TOKEN }}. Keep it gated on tags (on: push: tags: ['v*']) so ordinary pushes don't publish.

3.3 KiB Raw Blame History