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>
This commit is contained in:
thanhnv
co-authored by
Claude Opus 4.8
Claude Opus 4.8
parent
4918012199
commit
8c20cfde9f
@@ -0,0 +1,73 @@
|
||||
# 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
|
||||
```bash
|
||||
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}`
|
||||
```bash
|
||||
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:
|
||||
```bash
|
||||
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
|
||||
```bash
|
||||
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:
|
||||
```bash
|
||||
# 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.
|
||||
Reference in New Issue
Block a user