chore: release 5.3.1 - #119
Merged
Merged
Conversation
Promote from dev to stable: * fix(cloud): exclude config-shaped files from flow discovery (#114, closes dcd-cli#99) — a `config.yaml` sitting in a flows folder was picked up as a flow and blew up `processDependencies` with "Expected an array of steps". Detection is by shape, not filename, so several named configs can coexist in one folder. A flow merely *missing* its `---` separator still errors loudly rather than being silently dropped. * fix(cloud): reject malformed executionOrder instead of silently running in parallel (#117, closes dcd-cli#110) — the config was `yaml.load`ed and straight-cast, so an `executionOrder` in the wrong shape was ignored and every flow ran in parallel. A zod schema (`src/services/workspace-config.schema.ts`) is now the single source of truth, with `IWorkspaceConfig` inferred from it so the compile-time and runtime views cannot drift. * deps: bump the minor-and-patch group with 5 updates (#112), plus eslint-plugin-unicorn 72 -> 73 and pnpm/action-setup 6.0.9 -> 6.0.10. Behaviour changes users will notice: * A malformed `executionOrder` is now a hard error with a targeted message showing found-vs-expected. Anyone whose config was mis-shaped has been running flows in parallel without knowing; after this they get a clear failure instead. That is the point of the fix, but it is the one change that can turn a previously-green pipeline red. * Unrecognised top-level config keys emit a warning (with a did-you-mean for near-misses). Keys are preserved, not stripped — the config is forwarded to the API as `fields.workspaceConfig`, so stripping would silently alter the payload. * Config warnings go to stderr, so `--json` stdout stays parseable and the MCP server's JSON-RPC stdout channel stays clean. No platform prerequisite: both fixes are client-side (flow discovery and config validation). The submitted payload for an already-valid config is unchanged. Carries only the source delta — package.json version, CHANGELOG.md and the release-please manifests stay as release-please left them on production. Release-As: 5.3.1
14 tasks
finalerock44
added a commit
that referenced
this pull request
Aug 18, 2026
* chore: promote the grouped deps bump into 5.3.1 Promote from dev to stable, picking up the one change that landed after the 5.3.1 promotion (#119) and so missed the pending release PR (#120): * deps: bump the minor-and-patch group with 6 updates (#121) — @supabase/supabase-js 2.112.2 -> 2.112.3, js-yaml 5.2.3 -> 5.3.0, @types/node 26.1.2 -> 26.2.0, eslint 10.8.0 -> 10.8.1, tsx 4.23.11 -> 4.23.12, typescript-eslint 8.66.0 -> 8.67.0. Carries only `pnpm-lock.yaml`. Dependabot left `package.json` untouched — every range already admitted the new versions — so this changes nothing for npm consumers, who resolve from those ranges. It matters only for the bun-compiled standalone binaries, which bake in the locked versions. `Release-As: 5.3.1` keeps the pending release PR (#120) on 5.3.1 rather than rolling it to 5.3.2. Release-please regenerates the 5.3.1 section from this commit's bullet alongside #119's three, so the changelog ends up carrying all four entries. Verified locally, because CI cannot check this branch: `pnpm install --frozen-lockfile` (the lockfile agrees with production's package.json), `pnpm lint` (0 errors, the same 32 pre-existing warnings — the eslint 10.8.1 and typescript-eslint 8.67.0 bumps add no findings), `pnpm typecheck`, `pnpm build`, and `pnpm audit --audit-level moderate` (no known vulnerabilities). The integration tests did NOT run: dcd#1036 deleted `mock-api/`, which is also what fails CI's `lint-and-test`, at a step that runs before the linter. Release-As: 5.3.1 * ci: stop reaching into the private dcd repo for the mock-api `lint-and-test` has failed on every same-repo PR since dcd#1036 deleted `mock-api/` from the private devicecloud-dev/dcd repo this morning. CI checked that directory out over an SSH deploy key and ran `pnpm install` in it; the sparse-checkout now matches nothing, so the job dies at that step — before the linter — and takes #120, #122 and #123 down with it. Rather than re-point at a mock, this removes the linkage. dcd-cli is PUBLIC and was holding `DCD_SSH_DEPLOY_KEY`, a credential granting read access to the private repo, and pulling the API's `swagger.json` onto the runner on every same-repo PR. Deleting the checkout drops both. * The `Checkout dcd (mock-api)` and `Install Mock API dependencies` steps are gone, along with the `HAS_PRIVATE_ACCESS` gate that existed only to keep them off fork and Dependabot PRs. Every PR now takes the same path, so forks stop being second-class. * CI runs `pnpm test:unit` — a new script that is the existing runner with `--unit`. `test/unit/*` is pure and needs no backend, so unit coverage is kept rather than dropped along with the integration suite. * `scripts/test-runner.mjs` no longer defaults `MOCK_API_DIR` to `../../dcd/mock-api`. With no mock available it degrades to the unit suite and says so, instead of the bare ENOENT it throws today. Set `MOCK_API_DIR` and the integration specs run exactly as before. `DCD_SSH_DEPLOY_KEY` can now be deleted from the repo's secrets — nothing reads it. That is a separate manual step, not something this commit can do. Two things are genuinely lost, both worth stating plainly rather than discovering later: * `test/integration/*` no longer runs anywhere automatically. * With it goes the CLI<->swagger contract-drift check. Drift used to surface as a Prism 422 — that is how the `googlePlay` multipart break and the `tempPath` missing-example break were both caught. Nothing replaces it yet. Verified locally: `pnpm test:unit` and a bare `pnpm test` both run the unit suite only and print the notice; 81 pass and the 7 `flow-paths` failures are Windows-only, asserting POSIX paths against win32 `path`. The same specs ran green on ubuntu in the last full CI run (job 94750122384, 2026-08-14), which is the platform CI uses. `pnpm lint`, `pnpm typecheck`, `pnpm build` and `pnpm audit --audit-level moderate` are all clean.
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
1 participant
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.
Promote from dev to stable:
config.yamlsitting in a flows folder was picked up as a flow and blew upprocessDependencieswith "Expected an array of steps". Detection is by shape, not filename, so several named configs can coexist in one folder. A flow merely missing its---separator still errors loudly rather than being silently dropped.yaml.loaded and straight-cast, so anexecutionOrderin the wrong shape was ignored and every flow ran in parallel. A zod schema (src/services/workspace-config.schema.ts) is now the single source of truth, withIWorkspaceConfiginferred from it so the compile-time and runtime views cannot drift.Behaviour changes users will notice:
executionOrderis now a hard error with a targeted message showing found-vs-expected. Anyone whose config was mis-shaped has been running flows in parallel without knowing; after this they get a clear failure instead. That is the point of the fix, but it is the one change that can turn a previously-green pipeline red.fields.workspaceConfig, so stripping would silently alter the payload.--jsonstdout stays parseable and the MCP server's JSON-RPC stdout channel stays clean.No platform prerequisite: both fixes are client-side (flow discovery and config validation). The submitted payload for an already-valid config is unchanged.
Carries only the source delta — package.json version, CHANGELOG.md and the release-please manifests stay as release-please left them on production.
Release-As: 5.3.1
What & why
Type of change
fix— bug fixfeat— new featureperf— performance improvementrefactor— code change that's neither a fix nor a featuredocs— documentation onlychore/ci/build/test— tooling, no user-facing change!or PR notes aBREAKING CHANGE:)Checklist
pnpm lintpassespnpm typecheckpassespnpm buildpassesCHANGELOG.md(release-please handles this)README.md/STYLE_GUIDE.mdupdated if behaviour or output changedHow to test