fix(deps): refresh Node toolchain pin to v20.20.2 LTS - #2
Closed
ihistand wants to merge 1 commit into
Closed
Conversation
The pinned Node v24.13.0 in WORKSPACE had stale SHA256 hashes that no longer matched nodejs.org's served binaries: Expected: e798599612f4bb71333a3397ab0d095fd62214e115aea45aa858a145fc72d67e Actual: aa881151bd0f9f154a0424dd60a72e9ce10672619121658c278a24327ef46831 Bumped to Node v20.20.2 LTS (matches the node:20-bookworm base in Dockerfile.dev). Fresh SHA256 hashes pulled from nodejs.org/dist/v20.20.2/SHASUMS256.txt for all 5 platforms. This was a stale-pin issue (not a Node 24 problem) — nodejs.org appears to have re-published the v24.13.0 archives at some point. Pinning to an LTS line is more stable. Verified in Docker: ./scripts/docker-bazel build //protos:ts → success ./scripts/docker-bazel build //core/... → success ./scripts/docker-bazel test //core/... → 16/16 pass Full tree (//...) still blocked by a separate pre-existing upstream issue: tools/postgres/BUILD references @io_bazel_rules_docker which is not declared in WORKSPACE.
This was referenced May 27, 2026
ihistand
added a commit
that referenced
this pull request
Jun 4, 2026
#2 decision: workflow_settings.yaml uses a flat `warehouse:` string (bigquery/postgres/supabase) + flat defaults; the connection (with secrets) stays in the gitignored .df-credentials.json. This overturns the design doc's earlier "nested warehouse:{kind,connection}" call, which would have put secrets in committed config — flat matches Dataform's settings/credentials split and is already what the CLI, init, tests, example, and agent docs use. Harden it: workflowSettingsAsProjectConfig now rejects an unknown `warehouse:` value with a clear error instead of silently defaulting to BigQuery. TDD: core/main_test.ts "warehouse config" suite (accepts the three, defaults to bigquery when unset, RED→GREEN on rejecting "mysql"). CLAUDE.md item #2 marked resolved. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Collaborator
Author
|
Superseded: the Postgres reintegration + Dataform→SQLAnvil rename landed on |
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.
Summary
The pinned Node v24.13.0 in
WORKSPACEhad stale SHA256 hashes that no longer matched the binaries served from nodejs.org. Bumped to Node v20.20.2 LTS (matchesnode:20-bookworminDockerfile.dev) with fresh SHA256 hashes fromnodejs.org/dist/v20.20.2/SHASUMS256.txtfor all 5 platforms.This unblocks the proto-TS and core build/test targets that the rename PR #1 could not verify due to the broken Node pin.
Stale hash example
Was a stale-pin issue, not a Node-24-specific problem — nodejs.org seems to have re-published the v24.13.0 archives at some point. Pinning to an LTS line is more stable.
Verification (in Docker)
Test plan
Stack
Stacked on top of PR #1 (`rename/dataform-to-sqlanvil`). Merge order: #1 first, then this.
🤖 Generated with Claude Code