Skip to content

ci: move the test Spicepod off the removed v1beta1 version - #314

Open
claudespice wants to merge 1 commit into
spiceai:trunkfrom
claudespice:ci/spicepod-version-v1
Open

ci: move the test Spicepod off the removed v1beta1 version#314
claudespice wants to merge 1 commit into
spiceai:trunkfrom
claudespice:ci/spicepod-version-v1

Conversation

@claudespice

Copy link
Copy Markdown

Every open PR in this repo is red on Local Runtime, and none of them caused it.

Cause

test/scripts/spicepod.yaml still declares version: v1beta1. The runtime removed that version, so spiced refuses to start at all:

ERROR spiced: Failed to start Spice runtime: Unable to load spicepod .../test/scripts:
Unsupported Spicepod version in .../test/scripts: 'v1beta1'
Supported versions are: v1, v2 (or full semver: v1.0.0, v2.0.0-rc.1, etc.)

Because the runtime never comes up, the tests fail on transport errors rather than on anything they assert — connect ECONNREFUSED 127.0.0.1:8090 for the HTTP calls and 14 UNAVAILABLE: No connection established for Flight. The reported failures (expect(isHealthy).toBe(true), expect(isReady).toBe(true)) are symptoms of a dead runtime, which is why the error is easy to misread as a product regression.

Confirmed repo-wide, not branch-specific: it fails identically on #311, on lukekim's #313, and on dependabot #306 — a pure dependency bump that touches no source at all.

Fix

The Spicepod body is already v1-shaped, so the version string is the only change. v1 also matches the convention used across the runtime repo's own test Spicepods.

Not addressed here

Two other checks are red for reasons outside this repo's control, and this PR deliberately leaves them alone:

  • Cloud TestsSPICEAI_API_KEY and SCP_SPICEAI_TPCH_API_KEY arrive empty (Secret source: None), because GitHub withholds repo secrets from fork PRs.
  • VercelAuthorization required to deploy, same fork-secret restriction.

The runtime dropped v1beta1 as a valid Spicepod version, so spiced refuses
to start against test/scripts/spicepod.yaml:

    Failed to start Spice runtime: Unable to load spicepod test/scripts:
    Unsupported Spicepod version in test/scripts: 'v1beta1'
    Supported versions are: v1, v2

Because the runtime never comes up, every Local Runtime test fails on
ECONNREFUSED to 127.0.0.1:8090 and gRPC UNAVAILABLE rather than on anything
it was written to assert. That makes the whole suite red on every open PR
regardless of its contents.

The Spicepod body is already v1-shaped, so the version string is the only
change needed.
@vercel

vercel Bot commented Jul 27, 2026

Copy link
Copy Markdown

@claudespice is attempting to deploy a commit to the Spice AI Team on Vercel.

A member of the Team first needs to authorize it.

@claudespice

Copy link
Copy Markdown
Author

@copilot review

Note for a maintainer: CI here is gated on action_required — workflow runs for fork PRs need manual approval, and I do not have rights to approve them (Must have admin rights to Repository). So Local Runtime cannot demonstrate the fix until someone approves run 5f5c0956.

Verified without CI in the meantime: the runtime error itself enumerates the accepted values (Supported versions are: v1, v2), v1beta1 is explicitly rejected in crates/spicepod/src/lib.rs, and v1 is what the runtime repo uses across its own test Spicepods. The Spicepod body is unchanged.

@claudespice

Copy link
Copy Markdown
Author

Superseded by #315 — closing this once that merges.

#315 (ci: use Spicepod v2 in the test fixture) fixes the same trunk breakage this PR targets: test/scripts/spicepod.yaml declaring the removed version: v1beta1, which stopped spiced from starting so every Local Runtime test failed on ECONNREFUSED / 14 UNAVAILABLE. On #315's latest run all 6/6 Local Runtime jobs pass, so that fix is demonstrated working; its remaining red Cloud Tests are unrelated (they need repo secrets).

Both versions are valid — SUPPORTED_MAJORS in crates/spicepod/src/spec.rs accepts v1 and v2, and SpicepodVersion::default() is V2 — so #315's v2 is the more idiomatic choice of the two. No reason to review both; I'd suggest merging #315 and I'll close this out.

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