Skip to content

feat(cli): refresh the memory scaffold pin to 0.5 and compile it in CI#106

Open
powersemmi wants to merge 1 commit into
v0.5from
feat/98-refresh-memory-template
Open

feat(cli): refresh the memory scaffold pin to 0.5 and compile it in CI#106
powersemmi wants to merge 1 commit into
v0.5from
feat/98-refresh-memory-template

Conversation

@powersemmi

Copy link
Copy Markdown
Owner

Description

Closes the in-core, verifiable slice of #98 and lands the first step of #97 Phase 1 ("templates are never compiled") for the one broker the core owns.

  • Refresh the memory scaffold pin. ruststream new --broker memory emitted a project pinning ruststream = "0.3", so a project scaffolded off the 0.5 CLI started two minor versions behind. Bumped to "0.5". The template source already uses current 0.5 API (the publishing confirm handler omits the Context parameter, which works since publishing defs are generic over state), so only the pin was stale.
  • Compile the template in CI. The scaffolder is a template.replace over strings, so API drift or an invalid feature only surfaced in a user's first cargo build. Added a memory_scaffold_compiles test that renders the template and runs a nested cargo build against this workspace. The pinned ruststream = "0.5" is not on crates.io mid-release, so the generated manifest is patched to the workspace path - the test exercises the template's real feature list and code, sourced locally.
  • Opt-in like the UI test. The nested build is heavy, so it gates on RUN_SCAFFOLD_BUILD=1, mirroring RUN_UI_TESTS: the stable CI job sets it; the 1.85 job, coverage, and a local cargo test leave it unset and the test skips itself.

Scope: only memory (core-owned, compile-verified here). nats/nats-js keep their 0.3 pins - they are coupled to the unreleased ruststream-nats 0.5 and, per #97, move out to the broker repo where they can be CI-compiled against the real client. The Redis templates (#98) are authored in ruststream-fred under the same system.

Type of change

  • New feature (non-breaking change which adds functionality)
  • Breaking change

Checklist

  • My code follows the project's style guidelines (just check passes)
  • I have performed a self-review of my own code
  • My changes generate no new warnings (clippy runs with -D warnings)
  • I have added tests that validate my fix or new feature
  • New and existing tests pass locally (just test, and the gated build with RUN_SCAFFOLD_BUILD=1)

Related

`ruststream new --broker memory` scaffolded a project pinning `ruststream =
"0.3"`, so a fresh project off the 0.5 CLI started two minor versions behind.
Bump the embedded pin to "0.5".

The scaffold templates were never compiled (issue #97): a `template.replace`
on strings, so an API drift or an invalid feature only surfaced in a user's
first `cargo build`. Add a compile-check that renders the memory template and
runs a nested `cargo build` against this workspace (the pinned `ruststream =
"0.5"` is patched to the local path, since it is not on crates.io mid-release).
Memory is the only broker core owns; nats/nats-js move out under #97.

The build is heavy, so it is opt-in like the trybuild UI test: the stable CI
job sets `RUN_SCAFFOLD_BUILD=1`; the 1.85 job, coverage, and a local
`cargo test` leave it unset and the test skips itself.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant