.github/workflows/release.yml's "Publish sql.html to GitHub Pages docs/" step commits
the freshly built sql.html straight to docs/ on main. That relies on this repo's
GitHub Pages source being configured as "Deploy from a branch" (main / /docs),
which uses GitHub's legacy (non-Actions) Pages builder — confirmed via
gh api repos/Altinity/altinity-sql-browser/pages ("build_type": "legacy").
That legacy builder is unreliable for this repo right now:
- Cutting the v0.7.3 release (2026-08-06) pushed
f594ba0 (version bump) then the bot's
85f3bcc (docs: publish sql.html v0.7.3 to GitHub Pages). The Pages build for
f594ba0 sat in "status": "building", "duration": 0 for 40+ minutes
(gh api repos/Altinity/altinity-sql-browser/pages/builds/latest). A manual re-trigger
(gh api -X POST repos/Altinity/altinity-sql-browser/pages/builds) picked up 85f3bcc
and was still stuck the same way ("building", duration: 0) after 5+ more minutes
of polling.
- Looking at the build history for the same day, several unrelated pushes also came back
"errored" ("Page build failed", no further detail given): commits 6250625,
da79682ac, 5a531aad0. Only one push that day (d0fe736, the pre-release merge)
actually reached "built" — and that's the version (v0.7.2) still live at
https://docs.altinity.com/altinity-sql-browser/sql.html well after v0.7.3's GitHub
Release, Helm chart, and GHCR push all completed successfully.
So the release pipeline's GitHub Release / Helm-to-GHCR path is unaffected, but the
docs.altinity.com mirror silently goes stale for an unbounded amount of time after
every release, with no failure surfaced anywhere in release.yml's own run (the commit
step just pushes and exits 0 — GitHub's Pages build happens asynchronously, outside that
workflow run).
Suggested fix: move docs.altinity.com publishing off the legacy builder onto a
GitHub Actions Pages deployment — switch the repo's Pages source setting to "GitHub
Actions", and replace the current "commit sql.html to docs/ on main" step in
release.yml with actions/upload-pages-artifact + actions/deploy-pages (optionally
gated by actions/configure-pages). That removes the queue-stuck/opaque-error failure
mode entirely and gives a real, visible workflow run + logs for every publish instead of
an untracked async build.
Found by: /ship-adjacent release work (v0.7.3), 2026-08-06.
cc @DougTidwell
.github/workflows/release.yml's "Publish sql.html to GitHub Pages docs/" step commitsthe freshly built
sql.htmlstraight todocs/onmain. That relies on this repo'sGitHub Pages source being configured as "Deploy from a branch" (
main//docs),which uses GitHub's legacy (non-Actions) Pages builder — confirmed via
gh api repos/Altinity/altinity-sql-browser/pages("build_type": "legacy").That legacy builder is unreliable for this repo right now:
f594ba0(version bump) then the bot's85f3bcc(docs: publish sql.html v0.7.3 to GitHub Pages). The Pages build forf594ba0sat in"status": "building","duration": 0for 40+ minutes(
gh api repos/Altinity/altinity-sql-browser/pages/builds/latest). A manual re-trigger(
gh api -X POST repos/Altinity/altinity-sql-browser/pages/builds) picked up85f3bccand was still stuck the same way (
"building",duration: 0) after 5+ more minutesof polling.
"errored"("Page build failed", no further detail given): commits6250625,da79682ac,5a531aad0. Only one push that day (d0fe736, the pre-release merge)actually reached
"built"— and that's the version (v0.7.2) still live athttps://docs.altinity.com/altinity-sql-browser/sql.html well after
v0.7.3's GitHubRelease, Helm chart, and GHCR push all completed successfully.
So the release pipeline's GitHub Release / Helm-to-GHCR path is unaffected, but the
docs.altinity.commirror silently goes stale for an unbounded amount of time afterevery release, with no failure surfaced anywhere in
release.yml's own run (the commitstep just pushes and exits 0 — GitHub's Pages build happens asynchronously, outside that
workflow run).
Suggested fix: move
docs.altinity.compublishing off the legacy builder onto aGitHub Actions Pages deployment — switch the repo's Pages source setting to "GitHub
Actions", and replace the current "commit
sql.htmltodocs/onmain" step inrelease.ymlwithactions/upload-pages-artifact+actions/deploy-pages(optionallygated by
actions/configure-pages). That removes the queue-stuck/opaque-error failuremode entirely and gives a real, visible workflow run + logs for every publish instead of
an untracked async build.
Found by:
/ship-adjacent release work (v0.7.3), 2026-08-06.cc @DougTidwell