mainsync#140
Merged
Merged
Conversation
chore: post-transfer org rewrite + install.sh repair (namastexlabs/pg…
Bumps package.json 2.7.0 → 3.0.0. Merging to main triggers release.yml (push-to-main → prepare resolves 3.0.0 → tags v3.0.0 → build-tarballs → sign-attest → release-publish). No hand tag. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
release: v3.0.0 — autopg org transfer + install.sh bootstrap repair
trap 'rm -rf "$scratch"' RETURN in stage_from_pkg/stage_from_url leaks
globally (no set -o functrace) and re-fires in fetch_one's scope where
$scratch is undefined → under set -u: 'line 179: scratch: unbound
variable' → exit 1 on EVERY platform. Root cause of all v3.0.0 Build
failures AND the prior v2.7.0 sign-attest 'artifact not found' (build
never produced artifacts). Not org-transfer related.
Fix: ${scratch:-} makes the leaked-scope trap set -u-safe; cleanup
still works when scratch is set. Proven: set -u + leaked RETURN trap
no longer aborts.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ratch-unbound fix(release): scratch unbound var aborts every build-tarballs job (v3.0.0 GA blocker)
v3.0.0 tag never produced assets (build-tarballs scratch-unbound bug, fixed in #132). v3.0.1 is the first real v3 release. Merge to main → push tag v3.0.1 → build (now fixed) → sign-attest → release-publish. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
release: v3.0.1 — first published v3 (post build-tarballs fix)
BRIEF-v3-build-fix — three evidence-backed blockers kept every v3 tag (v2.7.0/v3.0.0/v3.0.2) from publishing anything. Bug #1a — autopg --version exited 1: bin/postgres-server.js (the file bun build --compile turns into the tarball's autopg, and what autopg-wrapper.cjs spawns) had no --version handler -> fell through to printHelp()+exit(1). tarball-smoke.sh swallowed stderr (2>/dev/null) and mislabeled it "binary not executable". Add a --version/-v handler using the bun --define BUILD_VERSION literal with a package.json fallback for the non-compiled wrapper path. Bug #1b — postgres --version exited 127 (libssl.so.1.1 / libicu60 not found): @embedded-postgres ships native/lib/ (libssl.so.1.1, libcrypto.so.1.1, libicu*.so.60, ...) + pg-symlinks.json, but fetch-postgres-bins.sh copied only bin/+share/, dropping lib/ entirely and never replaying the version symlinks postgres' DT_NEEDED resolves through (RUNPATH=$ORIGIN/../lib). Every shipped tarball's postgres was DOA on any modern host. Stage native/lib/ + replay pg-symlinks.json for all three source paths. Bug #2 — darwin-x64 sat queued forever on the unavailable macos-13 runner, holding run-conclusion null and (via the missing artifact) sinking sign-attest's aggregate -> the whole release-publish chain. Dropped from the build + sign matrices and the channel manifest; Intel macOS is a tracked follow-up. Bug #3 — the bump commit's required [skip ci] guard also suppressed the tag-push event, so build-tarballs.yml never fired. The bump job now explicitly gh workflow run build-tarballs.yml --ref <tag> (dispatch is skip-ci-immune, GITHUB_TOKEN-permitted) — [skip ci] stays intact. Local proof (linux-x64-glibc, full build->fetch->assemble->smoke --real): 11 passed, 0 failed (was 9 passed, 2 failed) — autopg 3.0.3 + postgres (PostgreSQL) 18.3, 48M tarball (in band). Fixture smoke 11/0 on all 5 platforms, shellcheck -S warning clean, workflows parse. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The v3.0.3 build-tarballs run (dispatched after #134 merged) proved the #1a/#1b fixes work — `Build linux-x64-glibc: completed/success` (was 9/2). It exposed 4 further blockers, all pre-existing infra/portability defects, not regressions: (5) release.yml lacked `actions: write`, so the Bug #3 "Kick build-tarballs" step hit `HTTP 403: Resource not accessible by integration` on the workflow_dispatch API (tag v3.0.3 was created + pushed fine, but the chain was never kicked). Grant actions:write. (6) linux-arm64 always failed "no @embedded-postgres pkg for linux-arm64" — yet @embedded-postgres/linux-arm64 IS published on the same 18.3.0-beta line. embedded_pkg_for just never mapped it. Map it + add to optionalDependencies. (CI's linux-arm64 job runs on ubuntu-24.04-arm, so the cpu=arm64 npm install resolves there; the darwin-arm64 leg already fetched fine on its arm64 runner.) (7) linux-x64-musl: @embedded-postgres ships NO musl build and no AUTOPG_POSTGRES_URL_TEMPLATE var is configured, so every musl fetch died and the missing artifact would sink sign-attest's aggregate (same failure mode as darwin-x64). Dropped from build + sign matrices + channel manifest; tracked follow-up. (8) assemble-tarball.sh:168 `tar_flags[@]: unbound variable` — macOS bash 3.2 + `set -u` + an empty array (BSD tar matches none of the GNU-only flags). Killed every darwin-* assemble. Use the `${arr[@]+"${arr[@]}"}` empty-safe expansion. Net published surface: linux-x64-glibc, linux-arm64, darwin-arm64 — all backed by a real @embedded-postgres package. Validation: glibc full build->fetch->assemble->smoke --real 11/0 (no regression); tar_flags idiom correct empty+populated under set -u; shellcheck -S warning clean; fixture smoke 11/0 on the 3 kept platforms; all 4 workflows parse; linux-arm64 npm EBADPLATFORM locally is a host x64 artifact (CI uses an arm64 runner). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…-tarflags-actions fix(release): v3.0.3 run follow-ups — actions:write, linux-arm64, drop musl, tar_flags
…a-verifier Blocker #9 — the reason no v3 ever published even after signing. The v3.0.4 chain proved #1a/#1b/#6/#8: all 3 Build jobs green, all 3 cosign keyless signatures + SLSA provenances produced. sign-attest's `aggregate` then died in `verify-published-artifacts.sh`: ✗ slsa-verifier FAILED (pass=9 fail=3) Real error (captured with the v3.0.4 bundles + slsa-verifier v2.6.0, not theorized): FAILED: matching bundle entry with content: unexpected tlog entry type: expected intoto:0.0.2, got dsse:0.0.1 `slsa-verifier verify-artifact` only understands slsa-github-generator provenance (Rekor `intoto:0.0.2`). The provenance here is produced by `actions/attest-build-provenance` (predicateType slsa.dev/provenance/v1, buildType actions.github.io/buildtypes/workflow/v1, Rekor `dsse:0.0.1`). slsa-verifier rejects every such bundle — `--builder-id` doesn't help; it's a format/tlog-type incompatibility, not a flag gap. This gate could never have gone green on a real release. Fix: verify with `gh attestation verify` (the first-class verifier for attest-build-provenance), offline via `--bundle`, anchored to the same Fulcio identity regex + OIDC issuer the cosign keyless check enforces so a stray attestation can't satisfy the gate. Drop the now-dead slsa-verifier installer; gh is preinstalled on GitHub runners; give the verify step GH_TOKEN. Proven against the real v3.0.4 signed bundles (download from sign-attest run 26113708890): linux-x64-glibc / linux-arm64 / darwin-arm64 all verify exit 0; a byte-flipped tarball fails exit 1. shellcheck clean; fixture sign-attest path untouched (keyed + --skip-slsa). Note (separate, documented): release.yml's bump dispatches build-tarballs via GITHUB_TOKEN; GitHub does not cascade `workflow_run` from a GITHUB_TOKEN-initiated run, so build→sign→publish must currently be hand-driven with a PAT. Auto-cascade is a tracked follow-up; not blind-implemented here (untestable under the merge constraints). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…t-provenance fix(release): verify provenance with gh attestation verify (slsa-verifier cannot)
…ll verbs (#10) Blocker #10 (found running the Phase-5 smoke on the published v3.0.5): the tarball `autopg` only knew --version/postmaster/serve. verify, doctor, install, etc. live in bin/autopg-wrapper.cjs + src/cli-install.cjs (the npm bin) and were never compiled in, so: - `autopg verify <tarball>` (Phase-5 smoke 2) exited 1 with a help dump - install.sh's own `"$INSTALL_DIR/autopg" install` is broken for the tarball distribution (never exercised — no v3 ever installed) The wrapper can't be the compile entry: it resolves an external bun from node_modules and spawns it on postgres-server.js — neither exists inside a single compiled binary. Fix: new bin/autopg-cli.js, the compile entry (build-binary.sh default ENTRY_POINT bin/postgres-server.js → bin/autopg-cli.js; knip.json entry updated). Mirrors the wrapper's dispatch MINUS the bun-spawn: - --version/-v → autopg <version> (BUILD_VERSION/pkg) - install/operator verbs → src/cli-install.cjs dispatch() in-process, scriptPath=process.execPath so pm2 supervises `<self> postmaster …` - postmaster/serve/help/… → delegate to bin/postgres-server.js The npm path (wrapper bin) is untouched. Proven on the compiled binary: autopg --version → autopg 3.0.6 (exit 0) autopg verify <v3.0.5 .tgz> → exit 0: "verified … as automagik-pgserve-release (cosign_signed)" autopg doctor → real diagnostics (commands/doctor.js) autopg install --help → cli-install usage (in-process, no daemon) autopg postmaster --help → postgres-server.js help Regression: tarball-smoke --real 11/0; fixture 11/0 ×3; shellcheck + eslint + knip clean. (`update` uses a computed __dirname require — pre-existing, non-smoke-critical, documented follow-up.) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…i-entry fix(release): unified compiled CLI entry — tarball autopg gets all verbs (#10)
The pm2 supervisor entry registered by 'pgserve install' / 'autopg install'
hardcoded the postmaster CLI args and never read runtime.enablePgvector
from settings.json. As a result:
autopg config set runtime.enablePgvector true
was silently dropped — the postmaster's parsePostmasterArgs() never saw
--pgvector, PostgresManager.enablePgvector stayed false, and
_doEnsurePgvectorFiles never ran. Fresh installs therefore had no
vector.so / vector.control on disk, and any consumer doing
CREATE EXTENSION vector hit:
ERROR: extension "vector" is not available
HINT: The extension must first be installed on the system where
PostgreSQL is running.
Found by @khal-os/brain v1.61.x dogfood — brain assumes pgvector
is available on the autopg socket and could not embed any documents
without it.
Fix: buildPm2StartArgs() now reads runtime.enablePgvector via the
same loadEffectiveConfig() pipeline already used for supervision
settings, and appends '--pgvector' to the postmaster args when true.
Default behavior unchanged (settings.json absent or false -> no flag).
Tests:
- Negative: install without enablePgvector setting -> --pgvector
NOT in pm2 postmaster args.
- Positive: install with settings.json runtime.enablePgvector=true
-> --pgvector IS in pm2 postmaster args.
Both new tests pass. The 6 pre-existing test failures in
pgserve url/port/status are unrelated host-XDG_RUNTIME_DIR leakage
(reproduces on main without this change).
Workaround for users on existing installs (until they re-run
'autopg install' or upgrade to a release with this fix):
autopg config set runtime.enablePgvector true
pm2 delete autopg-server
autopg install --port <PORT> --data <DATA> --socket-dir <SOCK>
…enable-pgvector fix(install): honor runtime.enablePgvector from settings.json
fix: route autopg auth through wrapper
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a unified entry point (bin/autopg-cli.js) for the compiled single-binary distribution, adds support for the auth subcommand, handles version flags, and packages the required shared libraries for PostgreSQL. It also switches SLSA provenance verification to gh attestation verify, ensures proper propagation of the enablePgvector setting, and prevents SPA fallbacks for missing concrete assets. The reviewer noted a critical issue where the newly added 'auth' subcommand is missing from the INSTALL_SUBCOMMANDS set in the compiled binary entry point (bin/autopg-cli.js), which would cause autopg auth to fail when executed from the compiled binary.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| 'config', | ||
| 'update', | ||
| 'restart', | ||
| 'ui', |
There was a problem hiding this comment.
The 'auth' subcommand is missing from INSTALL_SUBCOMMANDS in the compiled binary entry point (bin/autopg-cli.js), even though it was added to the wrapper (bin/autopg-wrapper.cjs). Without this, running autopg auth via the compiled binary will fall through to postgres-server.js and fail.
'ui',
'auth',
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
3 participants
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.
No description provided.