feat(api): bring the dashboard API into the workspace - #165
Draft
userAugustos wants to merge 3 commits into
Draft
userAugustos wants to merge 3 commits into
userAugustos wants to merge 3 commits into
Conversation
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: trueThanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
| - 8025:8025 | ||
|
|
||
| steps: | ||
| - uses: actions/checkout@v4 |
Move the dashboard API and the shared TypeScript config into this monorepo as the workspace packages @cc-forge/api and @cc-forge/tsconfig, copied verbatim from the canyon-os checkout. Bring the tooling the package needs with it: the Prettier, oxlint and editor configs at the root, the dev Postgres and Mailpit compose stack under .docker, the Docker build context ignore list, and the API end-to-end workflow. Wire the package into the root commands. packages/api/package.json gains lint, format, format:check and a unit-test script that runs without a local .env, so bun run check, bun run test and bun run build now cover the API alongside the Python packages.
The compose file the CLI ships for `canyonos serve` passed the api service CANYONOS_DISABLE_AUTH, which the API no longer reads, and left out AUTH_MODE and DEPLOY_WORKER, which it refuses to start without under the image's NODE_ENV=production. Name AUTH_MODE, DEPLOY_WORKER and FILE_STORAGE instead, matching the self-hosted stack the API is tested against, and cover the contract with a test over the shipped manifest.
Only the api's type check needs its own dist, because it resolves the package's published entry points. On the generic task the dependency reached the Python packages too and built both wheels on every check. Drop the docstring on the new CLI manifest test while here; the test name already says what it asserts.
userAugustos
force-pushed
the
feat/api-package
branch
from
September 21, 2026 20:46
9fee5c3 to
037c4c1
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes CAN-318
Summary
This brings the dashboard API into the monorepo as two TypeScript workspace packages, copied verbatim from the canyon-os checkout at f8be607.
packages/apibecomes the workspace package@cc-forge/apiandpackages/tsconfigbecomes@cc-forge/tsconfig, the shared base config the API compiles against. No package, identifier, database or container name changes, and no fixes to the copied code.The tooling those packages need comes with them. The Prettier, oxlint and editor configs land at the repository root. The dev Postgres 17 and Mailpit stack lands under
.docker, which is what the end-to-end suite runs against locally. The Docker build-context ignore list lands at the root, extended so the Python side of the repository, the virtual environment and the Homebrew formula stay out of the API image context. The API end-to-end workflow lands at its usual path, with its actions pinned by commit SHA the way the existing CI workflow pins them. The API image definition moves next to the package it builds, atpackages/api/Dockerfile, and still builds from the repository root.The package is wired into the root commands.
bun run checknow runs the API's lint, type check and format check alongside the three Python tasks.bun run testnow runs the API unit tests alongside the CLI, core and root Python suites.bun run buildnow writes the API'sdistalongside the two Python wheels. The root manifest gains the dev dependencies those scripts need and the docker and end-to-end helper scripts, and the lockfile is regenerated.The second commit realigns the CLI with the environment the API actually reads. The compose file the CLI ships for
canyonos servepassed the api service a flag the API no longer reads, and left out the three settings the API insists on when it runs under the published image. The service now names the auth mode, the deploy worker and the file storage provider, matching the self-hosted stack the API is tested against, and a new CLI test holds that contract in place.Test
bun install --frozen-lockfile- no changes, 289 installs checked across 424 packagesuv sync --locked- 53 packages checked, anduv lock --checkresolves with the lockfile unchangedbun run check- 7 tasks successful: the API lint over 134 files with no warnings, the API type check, the API format check, the API build the type check depends on, and the Python lint, type check and format check over 145 filesbun run test- 4 tasks successful: 64 API unit tests, 156 CLI tests, 257 core tests with 1 skipped, 15 root testsbun run build- 3 tasks successful: the APIdistplus the CLI and core wheelsbun run --filter @cc-forge/api typecheck- exits cleanbun run docker:upandbun api:test:e2e- no Docker daemon is reachable in the environment this was prepared in, so the end-to-end suite was not run locally. The workflow runs it on this pull request.packages/api/Dockerfile, which is new here, andpackages/api/package.json, which gains the scripts the root commands call.Known and accepted
The end-to-end suite runs only in the workflow for now, since the environment this was prepared in has no Docker daemon.
The dashboard web application and the published images come in the next pull request, which is also what restores the dropped manifest copy lines in the image definition.
The CLI stack version is deliberately unchanged. No image is published from this repository yet, so there is nothing new for the version to point at.
The CLI module that manages the stack needed no edit. It never referenced the removed flag, which lived only in the shipped compose file.