Keysat
aa407b5f67
Repo cleanup - Add top-level .gitignore (was missing; node_modules, .next, *.s9pk, image.tar, seed/data/*.db, log files, etc.) and a root README. - Delete legacy start9/0.3.5/ package (StartOS 0.3.5 wrapper, no longer the deploy target). - Delete start9-example-packaging/ (template from another project). - Delete planning docs (START9_PACKAGING_LOG.md, VERSIONING.md, STARTOS_0.4_UPGRADE_PROMPT.md, ICON_FILES_INDEX.md, etc.) — info now lives in the deploy guide and code comments. - Drop the standalone Dockerfile, docker-compose.yml, ICON_*, and dev log/build artifacts from the app dir. - Drop the v0.1.0:18/19/20 version files (they belonged to the legacy workout-log package and don't apply to the new id). Rename + new package - Rename app dir workout-planner/ -> proof-of-work/. - Rename StartOS package id workout-log -> proof-of-work; the new id makes this a brand new StartOS service (clean cutover from the old one rather than in-place upgrade). - Reset version graph; v1.0.0:1 is the seeded cutover release. The Dockerfile bakes a one-time /data snapshot and docker_entrypoint.sh copies it into the new volume on truly-fresh first boot only (both /data/app.db missing AND /data/.seeded absent). - Move start9/0.4-migration/ -> start9/0.4/; the old start9/0.4/ stub is gone. Curated exercise library (multi-user-aware) - proof-of-work/prisma/exercises.seed.json is the canonical library shipped to every install (164 exercises today, dumped from the live snapshot). - proof-of-work/scripts/sync-library.cjs (npm run sync-library) refreshes the JSON from start9/0.4/seed/data/app.db after refresh_seed.sh. - proof-of-work/prisma/seed.ts now reads from the JSON instead of a hardcoded 52-exercise array; runs at Docker build time to seed the fallback DB and on first boot for fresh installs. - proof-of-work/prisma/ensureExerciseLibrary.cjs runs on every container boot (from docker_entrypoint.sh) and INSERT OR IGNOREs every library entry for every user, keyed on (userId, name). Library updates flow to existing installs on package upgrade; user-custom exercises (isCustom=true) and any colliding names are never overwritten; removed exercises stay on existing installs (additive-only). Deploy guide (start9/0.4/DEPLOY_040.md) - Rewritten end-to-end for the workout-log -> proof-of-work cutover: refresh_seed, sync-library, build, sideload, verify, rotate creds, stop the old service, then post-cutover cleanup release v1.0.0:2.
78 lines
3.3 KiB
TypeScript
78 lines
3.3 KiB
TypeScript
import { setupManifest } from '@start9labs/start-sdk'
|
|
import { alertInstall, alertUpdate, long, short } from './i18n'
|
|
|
|
/**
|
|
* Proof of Work (proof-of-work) — StartOS 0.4 manifest.
|
|
*
|
|
* Contract invariants that MUST stay stable across all future releases so the
|
|
* 0.3.5 \u2192 0.4 data migration and subsequent upgrades remain safe:
|
|
* - package identifier = 'proof-of-work' (matches the 0.3.5 package)
|
|
* - volume name = 'main' (matches the 0.3.5 volume)
|
|
* - mount path = '/data' (matches the 0.3.5 mount)
|
|
*
|
|
* NOTE: do NOT write the literal two-character token "i"+"d" followed by ":"
|
|
* anywhere else in this file. s9pk.mk extracts PACKAGE_ID with a naive awk
|
|
* that matches on that substring and will concatenate multiple hits into a
|
|
* broken BASE_NAME (symptom: make warning "overriding commands for target
|
|
* 'proof-of-work'" and "No rule to make target .git/HEAD").
|
|
*/
|
|
export const manifest = setupManifest({
|
|
id: 'proof-of-work',
|
|
title: 'Proof of Work',
|
|
license: 'Proprietary',
|
|
packageRepo: 'https://github.com/your-org/proof-of-work-startos',
|
|
upstreamRepo: 'https://github.com/your-org/proof-of-work',
|
|
marketingUrl: 'https://github.com/your-org/proof-of-work',
|
|
donationUrl: null,
|
|
docsUrls: ['https://docs.start9.com/packaging/0.4.0.x/'],
|
|
description: { short, long },
|
|
volumes: ['main'],
|
|
images: {
|
|
main: {
|
|
source: {
|
|
dockerBuild: {
|
|
// Both `workdir` and `dockerfile` are resolved by start-cli
|
|
// relative to the PACKAGE directory (where this manifest
|
|
// lives), per the 0.4.0.x packaging docs. That means:
|
|
// workdir: '../..' -> Docker build context = repo root
|
|
// (two levels up from
|
|
// start9/0.4/). The
|
|
// Dockerfile's COPY paths such as
|
|
// 'proof-of-work/...' and
|
|
// 'start9/0.4/...' are
|
|
// resolved from there.
|
|
// dockerfile: './Dockerfile'
|
|
// -> <package-dir>/Dockerfile. That's
|
|
// where ours actually lives; the
|
|
// Dockerfile sitting OUTSIDE the
|
|
// workdir is fine -- Docker
|
|
// supports it via `-f <path>
|
|
// <context>` and buildkit resolves
|
|
// COPY paths against the context
|
|
// (workdir), not the Dockerfile's
|
|
// directory.
|
|
// DO NOT set dockerfile to './start9/0.4/Dockerfile'.
|
|
// That would resolve to
|
|
// start9/0.4/start9/0.4/Dockerfile
|
|
// (nonexistent), producing
|
|
// `resolve : lstat start9: no such file or directory`
|
|
// from buildkit before any layer runs.
|
|
workdir: '../..',
|
|
dockerfile: './Dockerfile',
|
|
},
|
|
},
|
|
// 0.4 beta is x86_64-only; expand to ['x86_64', 'aarch64'] post-beta.
|
|
arch: ['x86_64'],
|
|
},
|
|
},
|
|
alerts: {
|
|
install: alertInstall,
|
|
update: alertUpdate,
|
|
uninstall: null,
|
|
restore: null,
|
|
start: null,
|
|
stop: null,
|
|
},
|
|
dependencies: {},
|
|
})
|