Altinity / Altinity/altinity-sql-browser

docs.altinity.com Pages publish uses the flaky legacy builder, not GitHub Actions deployment

Offen
#626 0 Kommentare 0 Reaktionen 1 zugewiesene Person Auf GitHub ansehen

@DougTidwell arbeitet bereits daran.

Seit 06.8.2026.

inbox
Vorherrschende Sprache
TypeScript
Sterne
8
Forks
2
Ø Merge
1 Std. 34 Min.
Gemergte PRs (30 T.)
6

Beschreibung

.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

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
  3. Forke das Repository und arbeite in einem Branch.
  4. Öffne einen Pull Request, der die Issue-Nummer nennt.

Bewertung

Dieses Issue wurde noch nicht bewertet.

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.