Skip to content

chore(deps): refresh Go, pnpm, and build tooling - #7

Merged
steipete merged 1 commit into
mainfrom
chore/deps-refresh-20260830
Aug 31, 2026
Merged

steipete merged 1 commit into
mainfrom
chore/deps-refresh-20260830

Conversation

@steipete

@steipete steipete commented Aug 31, 2026 •

Copy link
Copy Markdown
Owner

Refresh the Go runtime dependencies and build tooling while preserving Go 1.25 source compatibility and macOS 12 support. No CLI behavior or application dependencies are added.

Dependency changes

Dependency Before After
Go toolchain 1.25.12 1.26.6
github.com/miekg/dns 1.1.72 1.1.73
golang.org/x/net 0.56.0 0.58.0
golang.org/x/sys 0.46.0 0.47.0
golang.org/x/sync (transitive) 0.21.0 0.22.0
pnpm 11.9.0 12.1.0
actions/setup-go v6 v7
Docker Go builder 1.25-alpine 1.26.6-alpine
Dockerfile frontend 1.7 1.26

go get -u ./... and go mod tidy regenerated the Go dependency files. DNS 1.1.73 replaces its old tools.go with a tool directive, so tidy removes the now-unused explicit go-cmp, x/mod, x/tools, and x/sync requirements. go mod why -m confirms this project does not need go-cmp, x/mod, or x/tools. zeroconf and its backoff module remain at their latest versions for the module paths they use.

pnpm regenerated its lockfile, including its own platform executables under package-manager dependencies. The application still has no npm dependencies. The pnpm 12 and setup-go 7 majors are included after reviewing their migration notes: this repository uses neither hosted Git package dependencies nor workspace peer cycles/configuration, and setup-go retains the go-version-file input on GitHub-hosted runners. checkout v7, golangci-lint-action v9, GoReleaser action v7, and Alpine 3.24 already track their current stable release lines.

References: pnpm 12.0 migration notes, pnpm 12.1, setup-go 7, DNS 1.1.73.

Verification

All completed successfully:

$ pnpm --version
12.1.0
$ pnpm install --frozen-lockfile
Already up to date
Done in 62ms using pnpm v12.1.0
$ GOTOOLCHAIN=go1.26.6 pnpm build
$ mkdir -p dist && go build -o dist/blu ./cmd/blu
$ GOTOOLCHAIN=go1.26.6 go test -count=1 ./...
ok  github.com/steipete/blucli/cmd/blu              0.412s
ok  github.com/steipete/blucli/internal/app         2.107s
ok  github.com/steipete/blucli/internal/bluos       1.890s
ok  github.com/steipete/blucli/internal/config      5.009s
ok  github.com/steipete/blucli/internal/discovery   3.308s
ok  github.com/steipete/blucli/internal/output      3.883s
ok  github.com/steipete/blucli/internal/spotify     4.513s
$ GOTOOLCHAIN=go1.26.6 go test -race -count=1 ./...
ok  github.com/steipete/blucli/cmd/blu              1.781s
ok  github.com/steipete/blucli/internal/app         3.728s
ok  github.com/steipete/blucli/internal/bluos       2.703s
ok  github.com/steipete/blucli/internal/config      3.995s
ok  github.com/steipete/blucli/internal/discovery   3.780s
ok  github.com/steipete/blucli/internal/output      2.957s
ok  github.com/steipete/blucli/internal/spotify     3.568s
$ GOTOOLCHAIN=go1.26.6 pnpm lint
0 issues.
$ GOTOOLCHAIN=go1.26.6 go run golang.org/x/vuln/cmd/govulncheck@latest ./...
No vulnerabilities found.
$ GOTOOLCHAIN=go1.26.6 go mod verify
all modules verified
$ GOTOOLCHAIN=go1.26.6 go mod tidy -diff
(no output; exit 0)

Go 1.25 source compatibility also passed explicitly:

$ GOTOOLCHAIN=go1.25.13 go test ./...
ok  github.com/steipete/blucli/cmd/blu              0.770s
ok  github.com/steipete/blucli/internal/app         2.201s
ok  github.com/steipete/blucli/internal/bluos       1.756s
ok  github.com/steipete/blucli/internal/config      1.185s
ok  github.com/steipete/blucli/internal/discovery   2.536s
ok  github.com/steipete/blucli/internal/output      3.195s
ok  github.com/steipete/blucli/internal/spotify     1.464s

The pnpm test helper also passed. Linux/amd64 and Windows/amd64 binaries cross-compiled with Go 1.26.6. Lint reports the existing gofumpt extra-rules deprecation warning but no findings. Codex autoreview completed scoped-clean with no accepted/actionable findings at its default P0 threshold.

Live CLI proof

A temporary Python HTTPServer on loopback served synthetic BluOS XML. This exercised the actually-built Go 1.26.6 executable through a real HTTP connection, XML parsing, and JSON output. The fixture returned:

<status state="pause" name="Integration Player" model="NODE" volume="18" mute="0" title1="Dependency refresh" artist="Synthetic fixture" />

The config file contained only {}. Actual commands and output:

$ ./dist/blu --config .git/deps-refresh-20260830/empty-config.json --device 127.0.0.1:55522 --discover=false --json status
{
  "state": "pause",
  "name": "Integration Player",
  "model": "NODE",
  "volume": 18,
  "mute": false,
  "title": "Dependency refresh",
  "artist": "Synthetic fixture"
}
$ ./dist/blu --config .git/deps-refresh-20260830/empty-config.json --device 127.0.0.1:55522 --discover=false --dry-run --trace-http volume set 19
http: GET http://127.0.0.1:55522/Volume?level=19&tell_slaves=1
PASS: parsed player XML through real HTTP; dry-run sent no volume request.

The server recorded exactly ['/Status'], proving the dry-run did not send a volume request. A separate read-only LAN discovery attempt found no physical players:

$ ./dist/blu --config .git/deps-refresh-20260830/empty-config.json --discover-timeout 5s --timeout 2s --json doctor
doctor: no devices discovered

The Docker image was built and run locally:

$ docker build --pull --build-arg VERSION=deps-refresh-20260830 -t blucli:deps-refresh-20260830 .
#18 naming to docker.io/library/blucli:deps-refresh-20260830 0.1s done
#18 unpacking to docker.io/library/blucli:deps-refresh-20260830 0.4s done
#18 DONE 2.8s
$ docker run --rm blucli:deps-refresh-20260830 --version
deps-refresh-20260830
$ docker run --rm blucli:deps-refresh-20260830 --help
blu — BluOS CLI

Usage:
  blu [--help] [--version] [--device <id|name|alias>] [--json] <command> [args]

CI reasoning and maintainer decision

Default-branch CI was green before this update: CI and Docker. Both are build/test workflows. The separate release workflow is tag-triggered; there are no scheduled monitoring workflows. No jobs, assertions, or tests were weakened or removed, and no release was triggered.

All branch and PR checks passed on the first attempt. Branch: CI and Docker. PR: CI and Docker. Linux, macOS, Windows, race, tidy, lint, and vulnerability checks are green. The default branch remains unchanged and green.

NEEDS-PETER: Go 1.27 requires macOS 13, dropping the macOS 12 compatibility provided by the current toolchain. This PR takes the supported Go 1.26.6 line instead. Recommendation: retain macOS 12 for this maintenance update and make the minimum-OS change explicit in a later release. See the Go 1.27 platform notes.

This PR is for orchestrator review; it must not be merged by the worker.

@clawsweeper

clawsweeper Bot commented Aug 31, 2026

Copy link
Copy Markdown

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

@clawsweeper clawsweeper Bot added merge-risk: 🚨 compatibility 🚨 Merging this PR could break existing users, config, migrations, defaults, or upgrades. P2 Normal priority bug or improvement with limited blast radius. proof: sufficient Contributor real behavior proof is sufficient. rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. status: ⏳ waiting on author ClawSweeper has contributor-facing work open and is waiting for author action. labels Aug 31, 2026
@steipete
steipete merged commit f6722d8 into main Aug 31, 2026
13 checks passed
@steipete
steipete deleted the chore/deps-refresh-20260830 branch August 31, 2026 11:43
@clawsweeper

clawsweeper Bot commented Aug 31, 2026

Copy link
Copy Markdown

Codex review: needs changes before merge. Reviewed August 31, 2026, 7:41 AM ET / 11:41 UTC.

ClawSweeper review

What this changes

Updates the Go toolchain and networking modules, pnpm metadata, Docker build image, and setup-go workflow action versions.

Merge readiness

⚠️ Needs maintainer review before merge - 2 items remain

Keep this owner-authored maintenance PR open: its Go and Docker validation is well evidenced, but the introduced pnpm lockfile contains two YAML documents and must be corrected before merge.

Priority: P2
Reviewed head: b2c977fbf436abfd6abf86299b8ec87986cbd1cb

Review scores

Measure Result What it means
Overall readiness 🦐 gold shrimp (3/6) The update has strong real CLI and container proof, but the malformed package-manager lockfile is a merge-blocking defect.
Proof confidence 🦞 diamond lobster (5/6) Sufficient (terminal): The supplied terminal transcript maps the updated Go/Docker build owners to a built blu executable, a real loopback HTTP request with parsed BluOS XML and JSON output, and a locally built Docker image; it shows successful after-change behavior, although it does not validate the malformed pnpm lockfile.
Patch quality 🦐 gold shrimp (3/6) 1 actionable review finding remain.

Verification

Check Result Evidence
Real behavior Verified Sufficient (terminal): The supplied terminal transcript maps the updated Go/Docker build owners to a built blu executable, a real loopback HTTP request with parsed BluOS XML and JSON output, and a locally built Docker image; it shows successful after-change behavior, although it does not validate the malformed pnpm lockfile.
Evidence reviewed 5 items Introduced duplicate lockfile document: The PR inserts a complete YAML document before the retained original lockfile, leaving a second --- document marker at line 101 rather than replacing the old document.
Structural check: A read-only YAML stream parse finds two root documents: the new package-manager dependency mapping and the old settings/importers mapping.
Documented affected workflow: The repository documents pnpm build, test, and lint helpers, so a malformed pnpm lockfile breaks an established developer workflow even though the Go-only CI jobs do not exercise it.
Findings 1 actionable finding [P1] Keep the pnpm lockfile to one YAML document
Security None None.

How this fits together

blucli is a Go command-line client for BluOS players. Its package-manager helpers invoke the Go build and test commands, while GitHub Actions and Docker use the declared toolchain to produce and validate binaries.

flowchart LR
  Dev[Developer pnpm helpers] --> Lock[pnpm lockfile]
  Lock --> Build[Go build and test]
  Mod[Go module toolchain] --> Build
  CI[GitHub Actions] --> Build
  Docker[Docker build] --> Build
  Build --> CLI[blu command-line client]
Loading

Before merge

  • Keep the pnpm lockfile to one YAML document (P1) - Remove the second document separator and retained old lockfile. The PR prepends a new pnpm 12 document but leaves the previous document beginning at line 102, so pnpm cannot reliably load the lockfile for the documented frozen-install/helper workflow; the Go-only CI jobs do not cover this path.
  • Resolve merge risk (P1) - Merging the two-document pnpm lockfile can make frozen installs or pnpm-based developer helpers fail despite the Go and Docker checks passing.

Findings

  • [P1] Keep the pnpm lockfile to one YAML document — pnpm-lock.yaml:101
Agent review details

Security

None.

Review metrics

Metric Value Why it matters
Changed surface 8 files affected; 121 added, 29 removed The update spans CI, release tooling, Docker, Go modules, and package-manager metadata.
pnpm lockfile delta 101 added, 0 removed The added block was prepended instead of replacing the existing 9-line lockfile.

Merge-risk options

Maintainer options:

  1. Regenerate the lockfile as one document (recommended)
    Replace the concatenated lockfile with pnpm 12.1.0's single generated document and verify a frozen install before merging.
Copy recommended automerge instruction
@clawsweeper automerge

Special instructions:
Regenerate pnpm-lock.yaml as one document, then verify pnpm install --frozen-lockfile and pnpm build.

Technical review

Best possible solution:

Regenerate and commit one canonical pnpm lockfile for pnpm 12.1.0, then retain the validated Go 1.26.6, Docker, and action updates.

Do we have a high-confidence way to reproduce the issue?

Yes—source reproducible: pnpm-lock.yaml contains two YAML documents, with the old lockfile beginning after the introduced separator at line 101. The review environment could not run Corepack because its cache location is read-only, but the malformed committed structure is directly observable.

Is this the best way to solve the issue?

No—the tooling upgrade is appropriate, but its lockfile must be regenerated as one document so pnpm's frozen-lockfile workflow remains usable.

Full review comments:

  • [P1] Keep the pnpm lockfile to one YAML document — pnpm-lock.yaml:101
    Remove the second document separator and retained old lockfile. The PR prepends a new pnpm 12 document but leaves the previous document beginning at line 102, so pnpm cannot reliably load the lockfile for the documented frozen-install/helper workflow; the Go-only CI jobs do not cover this path.
    Confidence: 0.97

Overall correctness: patch is incorrect
Overall confidence: 0.97

AGENTS.md: found, but no applicable review policy affected this item.

Codex review notes: model internal, reasoning high; reviewed against 677008ba4c22.

Labels

Label changes:

  • add P2: The defect is limited to the repository's documented developer package-manager workflow, but prevents a normal frozen pnpm setup.
  • add merge-risk: 🚨 compatibility: The PR changes the configured pnpm version and its lockfile in a way that can break existing development and automation commands.
  • add proof: sufficient: Contributor real behavior proof is sufficient. The supplied terminal transcript maps the updated Go/Docker build owners to a built blu executable, a real loopback HTTP request with parsed BluOS XML and JSON output, and a locally built Docker image; it shows successful after-change behavior, although it does not validate the malformed pnpm lockfile.
  • add rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦞 diamond lobster and patch quality is 🦐 gold shrimp.
  • add status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (terminal): The supplied terminal transcript maps the updated Go/Docker build owners to a built blu executable, a real loopback HTTP request with parsed BluOS XML and JSON output, and a locally built Docker image; it shows successful after-change behavior, although it does not validate the malformed pnpm lockfile.

Label justifications:

  • P2: The defect is limited to the repository's documented developer package-manager workflow, but prevents a normal frozen pnpm setup.
  • merge-risk: 🚨 compatibility: The PR changes the configured pnpm version and its lockfile in a way that can break existing development and automation commands.
  • rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦞 diamond lobster and patch quality is 🦐 gold shrimp.
  • status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (terminal): The supplied terminal transcript maps the updated Go/Docker build owners to a built blu executable, a real loopback HTTP request with parsed BluOS XML and JSON output, and a locally built Docker image; it shows successful after-change behavior, although it does not validate the malformed pnpm lockfile.
  • proof: sufficient: Contributor real behavior proof is sufficient. The supplied terminal transcript maps the updated Go/Docker build owners to a built blu executable, a real loopback HTTP request with parsed BluOS XML and JSON output, and a locally built Docker image; it shows successful after-change behavior, although it does not validate the malformed pnpm lockfile.

Evidence

Acceptance criteria:

  • [P1] pnpm install --frozen-lockfile.
  • [P1] pnpm build.
  • [P1] git diff --check.

What I checked:

  • Introduced duplicate lockfile document: The PR inserts a complete YAML document before the retained original lockfile, leaving a second --- document marker at line 101 rather than replacing the old document. (pnpm-lock.yaml:101, b2c977fbf436)
  • Structural check: A read-only YAML stream parse finds two root documents: the new package-manager dependency mapping and the old settings/importers mapping. (pnpm-lock.yaml:101, b2c977fbf436)
  • Documented affected workflow: The repository documents pnpm build, test, and lint helpers, so a malformed pnpm lockfile breaks an established developer workflow even though the Go-only CI jobs do not exercise it. (README.md:86, b2c977fbf436)
  • Tooling history: Recent local history shows sustained maintenance of the same CI, Docker, module, and pnpm tooling surface by the routing candidate. (pnpm-lock.yaml:102, 4014fe92374a)
  • Real behavior proof supplied: The PR body records an after-change built CLI querying synthetic BluOS XML over loopback and a locally built Docker image returning version and help output; this directly exercises the updated Go and Docker build paths. (Dockerfile:3, b2c977fbf436)

Likely related people:

  • steipete: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

  • Regenerate pnpm-lock.yaml as one document and add a fresh frozen-install and pnpm-build transcript, redacting any private paths or endpoints.

Rating scale

Score Internal tier Crab rank Meaning
6/6 S 🦀 challenger crab Exceptional readiness
5/6 A 🦞 diamond lobster Very strong readiness
4/6 B 🐚 platinum hermit Good normal PR; ordinary maintainer review
3/6 C 🦐 gold shrimp Useful, but confidence is limited
2/6 D 🦪 silver shellfish Proof or implementation needs work
1/6 F 🧂 unranked krab Not merge-ready
N/A NA 🌊 off-meta tidepool Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

  • ClawSweeper keeps one durable marker-backed review comment per issue or PR.
  • Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
  • A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
  • PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
  • Maintainers can also comment @clawsweeper review to request a fresh review only.
  • Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
  • Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
  • Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

merge-risk: 🚨 compatibility 🚨 Merging this PR could break existing users, config, migrations, defaults, or upgrades. P2 Normal priority bug or improvement with limited blast radius. proof: sufficient Contributor real behavior proof is sufficient. rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. status: ⏳ waiting on author ClawSweeper has contributor-facing work open and is waiting for author action.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant