workspace skill: make PR preview-comment step un-failable so a transient API error can't red the deploy#93
Closed
gas2own wants to merge 1 commit into
Closed
Conversation
gas2own
added a commit
that referenced
this pull request
Jul 16, 2026
…ct URL on private repos) Two latent bugs in the reusable Quarto deploy workflow made a freshly scaffolded repo's first PR look broken (red deploy check, no/wrong preview link) even when the site published fine: 1. The preview-comment gh api read was unguarded under set -e; a transient 5xx HTML body breaks --jq and abORTS the deploy after publish. Now the block runs under set +e and closes on a guaranteed-success command. 2. The preview URL was hardcoded to <owner>.github.io/<repo>, dead on private/internal repos that serve from an obfuscated *.pages.github.io domain. Now resolved from the Pages API with fallback; deploy job and scaffold docs.yml template grant pages: read. Supersedes #91, #92, #93. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…'t red the deploy
The deploy job publishes the site to gh-pages and then posts/updates a
best-effort "📄 Preview:" comment on the PR. That comment block ran under the
step's default `set -e`, and the first call — `existing=$(gh api ... --jq ...)`
— had no guard. When the GitHub API returns a 5xx, `gh api` emits an HTML error
page that breaks `--jq` parsing ("invalid character '<'"), the command
substitution exits non-zero, and under `set -e` a bare assignment aborts the
whole step. Result: an otherwise-successful publish (gh-pages already updated)
shows a red `docs / deploy` check.
This reproduced on a freshly-scaffolded workspace repo during a brief GitHub API
outage, contradicting the block's own "Best-effort — a comment hiccup shouldn't
fail an otherwise-successful publish" comment.
Fix: disable errexit for the whole comment block and guard the read the same
way the writes already are, so no comment-time API hiccup can fail the deploy.
Previews stay attached to the PR via the comment; robustness is the only change.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
gas2own
force-pushed
the
fix-preview-comment-cannot-fail-deploy
branch
from
July 16, 2026 23:25
d2b1280 to
4de2c9a
Compare
Contributor
Author
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
1 participant
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.
What
In the workspace-skill shared workflow
.github/workflows/workspace-quarto-site.yml, thedeployjob's preview-comment block now runs withset +eand guards its read call, so a transient GitHub API error during comment posting can no longer fail an otherwise-successful publish.Why
The block is documented as "Best-effort — a comment hiccup shouldn't fail an otherwise-successful publish", but it didn't behave that way. The first call —
existing=$(gh api … --jq …)— had no||guard and ran under the step's defaultset -e. When the GitHub API returns a 5xx,gh apiemits an HTML error page;--jqthen fails withinvalid character '<' looking for beginning of value, the command substitution exits non-zero, and underset -ea bare assignment aborts the whole step.Net effect: the site was published to
gh-pages, but thedocs / deploycheck went red purely because the follow-up comment fetch hit a transient API blip.This reproduced on a freshly-scaffolded workspace repo during a brief GitHub API outage — exactly the "onboarding should be bulletproof" case. Log excerpt:
```
gh-pages already up to date
invalid character '<' looking for beginning of value
##[error]Process completed with exit code 1.
```
Confirmed the
set -esemantics:bash -e -c 'x=\$(bash -c "exit 1"); echo reached'never printsreached.Change
set +e/set -e.|| echo "::warning::…"guard to the read call, matching the existing guards on the PATCH/POST writes.Previews stay attached to the PR via the same
📄 Preview:comment +/pr-preview/pr-<N>/URL; only robustness changes. YAML validated withyaml.safe_load.🤖 Generated with Claude Code