[ajitpratap0]

Summary

Post-tag follow-ups for v1.16.0 (these fail CI before the tag exists).

• doc.go Version History gains v1.16.0.
• Version banners: go run ./scripts/gen-readme-metrics (README metrics block, docs/COMPARISON.md).
• Integrations: integrations/gorm and integrations/opentelemetry require github.com/ajitpratap0/GoSQLX v1.16.0 (were v1.14.0); tidy, build and tests pass.
• Install pins: @v1.16.0 in docs/guides/lint-sql-in-ci.md and the lint-in-CI website article.
• Parse benchmarks re-measured (Apple M4, BenchmarkPerformanceBaseline, median of 20 runs, 2026-10-22): SELECT 349 ns, INSERT 406, CTE 644, window 631, complex 1234. Under identical conditions v1.16.0 SimpleSelect is 26% faster than v1.15.0 (345 vs 469 ns, benchstat p=0.000 n=10); the absolute figure sits above the 2026-10-13 318 ns because of ambient machine load. Updated metrics.json (runs: 20), README, llms.txt, website/src/data/metrics.ts and performance_baselines.json current_performance (CI thresholds unchanged).
• Competitor benchmarks: results from the v1.16.0 tag's bench-compare publish run (commit e9c5db9) → benchmarks/compare/results/latest.{json,txt} and an exact copy in website/src/data/competitor-benchmarks.json.
• Glama sync: GoReleaser publishes releases with GITHUB_TOKEN, which starts no workflows, so glama-sync.yml never ran for v1.16.0. It gains a workflow_dispatch tag input; release.yml dispatches it after GoReleaser (actions: write). Build pinned to the tag's commit; Glama build image Go 1.26.1 → 1.26.10. Note: GLAMA_SESSION_COOKIE is not set, so the Glama build trigger still skips until the maintainer adds it.
• Dialect wording: llms.txt and CLAUDE.md say 8 dialects with dedicated grammar, and that --dialect also accepts generic, bigquery, redshift (matches README since fix: single-source core lint rules, derive CLI version, fix README dialect note #853).

Test Plan

• go run ./scripts/gen-readme-metrics --check and --claims --about "<current About>": ok at v1.16.0
• node website/scripts/check-metrics-drift.mjs: passed
• go test -run TestPerformanceRegression ./pkg/sql/parser/: ok
• integrations: go mod tidy && go build ./... && go test ./... in both modules
• pre-commit fmt/vet/short tests; workflow YAML parses
• After merge: gh workflow run glama-sync.yml -f tag=v1.16.0 to sync this release

Breaking Changes

None.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RkzVu3JY9Y6BRWfjesWts9

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
gosqlx-website	Ignored	Preview	Oct 22, 2026 3:33pm UTC

[github-actions]

Claude finished @ajitpratap0's task in 27s —— View job

---

Review of PR #855

Most of this is mechanical (metrics, pins, benchmark data) and looks consistent. I reviewed the workflow, go.mod, doc.go, llms.txt, CLAUDE.md, performance_baselines.json and metrics.json diffs. I did not run the tests or the generators, and I did not read the large benchmark result files.

Bug: VERSION is empty in the commit step

.github/workflows/glama-sync.yml, "Commit and push" step. VERSION is set inside the "Bump version in glama.json" step's shell. Shell variables don't carry across steps, so here it expands to an empty string. The commit message becomes chore(glama): sync version to [skip ci], and the "already at" message is blank too. Before this PR, both steps used ${GITHUB_REF_NAME#v}, which is why it worked.

Fix: either add env: RELEASE_TAG: ${{ inputs.tag || github.ref_name }} to the commit step and compute VERSION="${RELEASE_TAG#v}" there, or write echo "VERSION=$VERSION" >> "$GITHUB_ENV" in the bump step.

Other concerns (workflows)

• Dispatch from a tag run. release.yml runs gh workflow run glama-sync.yml --ref main, and the sync job checks out main for workflow_dispatch. It then pushes the glama.json bump to main. If branch protection blocks github-actions[bot] from pushing directly, that push fails. The job is continue-on-error, so the failure would be silent. It's worth confirming this push works on a protected main.
• Checkout vs. build commit. The glama.json bump lands on main's head, but the Docker build is pinned to the tag's commit. That is fine for your intent, but the tagged commit's glama.json will keep the old version. This matches the pre-existing design, so just be aware of it.
• Commit lookup. gh api repos/.../commits/${RELEASE_TAG} resolves tags, but if the tag is annotated it still returns the commit SHA, so it's OK. If the lookup fails, COMMIT_SHA is empty, because the $(...) assignment isn't checked. Consider set -euo pipefail or an explicit empty check before the cookie check.
• Token scope. actions: write is scoped to the release job, which is appropriate. The dispatch step is continue-on-error, so failures won't block the release. That's reasonable, but a failure is easy to miss.
• Go version. The Glama build image moved from Go 1.26.1 to 1.26.10. Please confirm 1.26.10 exists on go.dev/dl at merge time, because a typo here only shows up when the build runs.

Docs and data

• integrations/gorm/go.sum and integrations/opentelemetry/go.mod bumped to v1.16.0. The OpenTelemetry module's go.sum isn't in the changed-file list, so please check it didn't need an update. The PR says tidy passes, so this is probably fine.
• The perf numbers are internally consistent across metrics.json, llms.txt, performance_baselines.json and the README. The 349 ns figure is higher than the earlier 318 ns, and the PR explains that as machine load. The "26% faster than v1.15.0" claim rests on a same-session comparison, which is sound. CI thresholds are unchanged, so there's no regression-test risk.
• llms.txt and CLAUDE.md mention "11 names" for --dialect: 8 dedicated plus generic, bigquery and redshift. That adds up.
• The doc.go v1.16.0 entry is fine.

Test plan

The final item (gh workflow run glama-sync.yml -f tag=v1.16.0) should wait until the VERSION bug above is fixed. Otherwise it will make a commit with a blank version in the message. As the PR notes, the build trigger will still skip until GLAMA_SESSION_COOKIE is set.

[github-actions]

Claude encountered an error after 0s —— View job

---

I'll analyze this and get back to you.

[github-actions]

Claude finished @ajitpratap0's task in 20s —— View job

---

Review of PR #855

Most of this is mechanical (metrics, pins, benchmark data, version banners) and looks consistent. I read the workflow diffs in full. I did not run the tests or generators, and I did not read the large benchmark result files.

Resolved since the last review

• VERSION in the commit step. The earlier review flagged this as empty. The latest commit (2fc7ce5) fixes it: the "Commit and push" step now sets RELEASE_TAG in env and computes VERSION="${RELEASE_TAG#v}". The commit message and the "already at" message now get the right value.

Remaining concerns (.github/workflows)

• Push to protected main. For workflow_dispatch, the bump job checks out main and pushes the glama.json change there. If branch protection blocks github-actions[bot], the push fails. The job is continue-on-error, so you would not see it. Please check the job log after the first dispatch.
• Unchecked commit lookup. COMMIT_SHA="$(gh api ...)" is not checked. If the lookup fails (for example a typo in tag), the SHA is empty. When the cookie is set, the Python step then fails with a KeyError or sends an empty pinnedCommitSha. An explicit check would give a clearer error: [ -n "$COMMIT_SHA" ] || { echo "::error::cannot resolve $RELEASE_TAG"; exit 1; }.
• Dispatch step in release.yml. It is continue-on-error and uses actions: write scoped to the release job, which is appropriate. A failure there is easy to miss, so check the release run log once.
• Pinned and tagged glama.json differ. The Docker build is pinned to the tag's commit, but the version bump lands on main. That matches the earlier design. The tagged commit's glama.json keeps the old version.
• Go version. Please confirm that go1.26.10.linux-amd64.tar.gz exists on go.dev/dl before merging. A wrong version only shows up when the build runs.
• GLAMA_SESSION_COOKIE. It is still unset, so the build trigger skips with a warning (as the PR notes).

Docs and data

• The performance figures are consistent across metrics.json, llms.txt, performance_baselines.json and the README. The explanation for 349 ns versus 318 ns (machine load) is reasonable. The "26% faster than v1.15.0" claim comes from a same-session comparison, so it holds. CI thresholds are unchanged, so the regression test is not at risk.
• The integration modules are bumped to v1.16.0. integrations/opentelemetry/go.sum is not in the changed list. Since go mod tidy, build and tests passed, this is probably fine. I did not check it myself.
• The doc.go entry, the install pins, and the dialect wording in llms.txt and CLAUDE.md (8 dedicated dialects plus generic, bigquery and redshift) look correct.

Verdict

There are no blockers. The COMMIT_SHA check is a small hardening worth adding. After merge, run gh workflow run glama-sync.yml -f tag=v1.16.0 and look at the bump job's push result.

[github-actions]

Claude finished @ajitpratap0's task in 16s —— View job

---

Review of PR #855

I read the workflow diffs (glama-sync.yml, release.yml) against origin/main. I did not run the tests or generators, and I did not read the large benchmark data files.

The earlier VERSION bug is fixed. The "Commit and push" step now sets RELEASE_TAG in its own env: and computes VERSION="${RELEASE_TAG#v}" itself (commit 2fc7ce5). The commit message and the "already at" message will now show the real version. The [ ] test-plan item (gh workflow run glama-sync.yml -f tag=v1.16.0) is safe to run after merge.

Remaining workflow notes (non-blocking)

• Protected main. On dispatch the job checks out main and runs git push for the glama.json bump. If branch protection blocks github-actions[bot], the push fails. Since the dispatch step in release.yml is continue-on-error, this is easy to miss. Check the first manual run's logs.
• Empty commit SHA. COMMIT_SHA="$(gh api .../commits/${RELEASE_TAG} --jq .sha)" is not checked. If the lookup fails, the SHA is empty. Add [ -n "$COMMIT_SHA" ] || { echo "::error::could not resolve $RELEASE_TAG"; exit 1; }. The lookup also runs before the cookie check, so a transient API failure aborts the step even when the cookie is unset.
• glama.json and the tag. The version bump lands on main's head, while the build is pinned to the tag's commit. The tagged commit's glama.json therefore keeps the old version. This is the existing design.
• Go 1.26.10. Confirm go1.26.10.linux-amd64.tar.gz exists on go.dev/dl before merging. A bad version only shows up when the Glama build runs.
• Permissions. Scoping actions: write to the release job is appropriate.

Docs and data

• The perf numbers match across metrics.json, llms.txt, performance_baselines.json and the README. CI thresholds are unchanged, so there is no regression-test risk.
• The 349 ns figure sits above the earlier 318 ns, and the PR explains this as ambient machine load. The "26% faster than v1.15.0" claim comes from a same-session comparison, which holds up.
• go.mod bumps for the integrations and the @v1.16.0 install pins are consistent. integrations/opentelemetry/go.sum isn't in the changed-file list. The PR says tidy and tests pass, so it likely didn't need an update.
• The doc.go entry and the dialect wording in llms.txt and CLAUDE.md (8 dedicated + generic, bigquery, redshift) look correct.

Overall this is good to merge. Only the optional SHA check above is worth adding.