publish: pre-flight every package before the first publish
npm has no multi-package transaction and the OIDC credential cannot unpublish, so all-or-nothing is decided before the first write: every package in the run's set is checked for a stamped version, no placeholder dependency pins, a packable tarball, and (platform packages) the binaries actually inside it. One failure means nothing is published.
Merge pull request #20 from dekaruntime/fix/autopilot-hardening
publish: make the hourly schedule real, serialize runs, pin npm major
publish: make the hourly schedule real, serialize runs, pin npm major
The schedule event fell into the resolve step's 'unsupported event' branch, so the hourly fallback could never publish anything. The publish job is now a two-leg matrix (dsc, then deka; max-parallel 1): a tag or dispatch names one family and the other leg no-ops, the schedule runs both. Job-level concurrency keeps two publish runs from overlapping. npm is pinned to major 12 instead of @latest.
Merge pull request #19 from dekaruntime/fix/lockstep-single-path
Single publish path: remove publish.yml, make publish-runtime.yml resumable
publish: straight to latest, drop the next→promote step
Trusted publishing's OIDC credential only covers npm publish; npm dist-tag add fails with E401 (seen on run 35056200218, dsc 0.53.5). Publish order is the safety instead: platform packages, then the launcher, then create-deka-app, each read back before the next.
Single publish path: one workflow, resumable, never commits a version bump
create-deka-app was reachable through three separate GitHub Actions
surfaces: publish.yml's standalone v* tag (a scaffolder-only release
requiring a hand-bumped version committed to git), publish-runtime.yml's
lockstep deka family run (which stamps create-deka-app's version in
the working tree only, never committing it), and ci.yml (a separate test
job). The two publish paths disagreed on how a version gets set, and the
repo must never carry a real version bump in git -- so this collapses
everything into the single file publish-runtime.yml (kept at that
exact name: npm trusted publishing for the 8 @dekaruntime/* packages is
configured against it), with two jobs:
test: runs on every trigger (pull_request, push to main, tag pushes,
repository_dispatch, schedule, workflow_dispatch) -- checkout, Node 22,
the same npm install -g npm@latest the publish job uses, npm ci,
npm test, and the usage-message assertion that used to live in
publish.yml. contents: read only, no environment, no id-token.publish: needs: test, gated with
if: github.event_name != 'pull_request' && github.event_name != 'push' || startsWith(github.ref, 'refs/tags/')
so it only runs for a deka-v*/dsc-v* tag push, repository_dispatch,
schedule, or workflow_dispatch -- never a pull_request or a plain push
to main. Everything already in this job is unchanged (resolve version,
resumable check, dsc pin, download/verify, stamp all 9 packages,
publish tolerant of already-published, read back, promote to latest,
tag), minus the now-redundant standalone "Test create-deka-app" step.Root package.json now carries a "0.0.0" placeholder instead of a real
semver, matching the "never commit a version bump" rule: the real
version only ever exists in the working tree during a publish job run,
stamped by its "Stamp versions" step. The runtime pin logic
(src/scaffold.js resolveRuntimeVersion) needed no change -- it already
just forwards whatever ownVersion it's given, so it keeps pinning the
stamped version at publish time and 0.0.0 in every other context (local
dev, tests). The registry-lookup fallback for a create-deka-app release
that ships before its matching runtime build
(resolveLatestRuntimeVersion) is unaffected and stays in place.
Also added package-lock.json (previously absent -- the repo has zero
dependencies, so npm install never generated one) so npm ci in the
new test job has something to install from.
publish is made resumable, so a half-completed run (for example: the 8
runtime packages reach next/latest but create-deka-app's own publish
step fails) is finished by the next run instead of being skipped
forever:
npm publish step now checks npm view "<name>@${VERSION}" version first and skips its own publish (logging why) when that exact
version is already on the registry, so a resumed run doesn't fail on
npm's "cannot publish over the previously published versions"
(E403/EPUBLISHCONFLICT) refusal for packages a prior run already
published.Tested: npm ci && npm test passes all 69 tests with the placeholder
version in the tree (including the e2e and unit tests that read
create-deka-app's own version and assert the scaffolded pin matches
it). Workflow YAML validated with ruby -ryaml and actionlint, both
clean.
Merge pull request #18 from dekaruntime/feat/lockstep-versioning
Lockstep-version create-deka-app with @dekaruntime/deka
Lockstep-version create-deka-app with @dekaruntime/deka
create-deka-app now versions in lockstep with the deka runtime it scaffolds: create-deka-app@X.Y.Z always pins @dekaruntime/deka@X.Y.Z -- its own version -- rather than a separate 0.0.x release line resolved from a registry lookup at scaffold time. The pin is now reproducible and needs no network call; the registry lookup from PR #11 survives only as a fallback for the case where the exact matching runtime version isn't published yet, with a clear log message and never a silently-pinned nonexistent version (the 0.0.3 ETARGET bug).
publish-runtime.yml's deka-family run now also stamps, tests, and publishes create-deka-app as part of its all-or-nothing boundary -- after the launcher, included in the registry read-back and the next -> latest promotion. dsc-family runs and the standalone v* tag path (publish.yml) are unchanged.
Claude-Session: https://claude.ai/code/session_01XHuN9xFKcoJaoTJfBwxsb1
Merge pull request #17 from dekaruntime/release/0.0.6
release: create-deka-app 0.0.6
release: create-deka-app 0.0.6 (next steps say deka dev)
Claude-Session: https://claude.ai/code/session_01XHuN9xFKcoJaoTJfBwxsb1