ci: fail the deploy when it cannot deploy, and prove the alias moved - #12
Conversation
dna.suedeai.ai has not been serving main. Live right now, the Organization node carries no foundingDate and the page ships two JSON-LD blocks; main sets foundingDate '2024' and consolidated the graph in #11 (77b6721, 2026-08-31). The commit merged, the Actions tab went green, and nothing shipped. Two causes, both fixed here. 1. The credential check set `ready=false` when VERCEL_TOKEN was missing and every later step carried `if: steps.creds.outputs.ready == 'true'`. So the job skipped its way to success. A deploy workflow that cannot deploy is a failure, not a skip. It now checks all three secrets, writes which are missing to the step summary, emits ::error:: and exits 1. The nine dead per-step guards are gone with it. 2. "Verify production is serving" only asserted a 200. The host answered 200 throughout the entire period when main was never deployed, so that check could never have caught this. Next chunk filenames are content-hashed, so the step now pulls the chunk set from both the deployment just created and from dna.suedeai.ai and requires them to match - which is the thing we actually care about: did the production alias move to this build. If the deployment URL cannot be read it warns rather than failing, so a genuine deploy is never failed by a flaky fetch. Verified: the workflow parses as YAML, the new verify step passes `bash -n`, and the chunk-extraction logic was dry-run against the live site (7 chunks, self-comparison matches). This does not by itself put main on production - the repository still has no VERCEL_TOKEN, VERCEL_ORG_ID or VERCEL_PROJECT_ID. That needs someone with admin on Suede-AI/dna to add them under Settings -> Secrets and variables -> Actions, then run this workflow via workflow_dispatch. The difference is that until that happens the workflow will say so in red instead of green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 47b0b4cac1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if [ "$live" = "$fresh" ]; then | ||
| echo "production is serving the deployment just built" | ||
| exit 0 |
There was a problem hiding this comment.
Verify deployment identity instead of client chunks
For server-rendered-only changes—such as the JSON-LD change in src/app/layout.tsx that motivated this workflow—the old and new deployments can reference identical client JavaScript chunks because the browser bundle did not change. In that scenario the stale custom domain and fresh deployment produce equal lists here, so the workflow exits successfully even though production is still serving different HTML; compare an explicit commit/build marker or the alias target instead.
AGENTS.md reference: AGENTS.md:L3-L4
Useful? React with 👍 / 👎.
https://www.linkedin.com/company/suede-labs-ai 301s to https://www.linkedin.com/company/suede-labs. LinkedIn only redirects a vanity slug within the same company page, so the destination is the current canonical URL for the page this estate already claims. It matters more than an ordinary redirect because most of these occurrences are in JSON-LD `sameAs`, the field search and answer engines use to decide which accounts belong to the same entity. An entity's identity links should resolve directly rather than through a hop. Confirmed with the owner (2026-09-03) that the destination page is theirs. Part of an estate-wide sweep: 82 occurrences across 16 repos, verified to be the only line changed in every file. Occurrences inside JasonColapietro/suede-geo's docs/seo-audits/ are deliberately left alone - those are dated records of what an earlier audit saw, and they are not published. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Added one more commit after this PR was opened, so the description above no longer covers it in full.
Part of an estate-wide sweep: 82 occurrences across 16 repos, one line changed per occurrence and nothing else. Still mechanical — no copy, headings, titles, descriptions or claims. |
dna.suedeai.ai has not been serving
main.Live right now, the Organization node carries no
foundingDateand the page ships two JSON-LD blocks.mainsetsfoundingDate: '2024'and consolidated the graph in #11 (77b6721, 2026-08-31). The commit merged, the Actions tab went green, and nothing shipped.That is the worst failure mode for this repo: every SEO fix merged here would have been invisible.
Two causes, both fixed.
1. The workflow skipped its way to success
The credential check set
ready=falsewhenVERCEL_TOKENwas missing, and every later step carriedif: steps.creds.outputs.ready == 'true'. A job that skips all its work still passes.It now checks all three secrets, writes which are missing to the step summary, emits
::error::, and exits 1. The nine now-dead per-step guards are gone with it.A deploy workflow that cannot deploy is a failure, not a skip.
2. The verify step could never have caught this
Verify production is servingonly asserted a 200. The host answered 200 throughout the entire period whenmainwas never deployed.Next chunk filenames are content-hashed, so the step now pulls the chunk set from both the deployment it just created and from
dna.suedeai.ai, and requires them to match — which is the thing that actually matters: did the production alias move to this build. If the deployment URL cannot be read it warns rather than fails, so a genuine deploy is never failed by a flaky fetch.Verification
ifbash -nThis does not by itself fix the deploy
The repository still has no
VERCEL_TOKEN,VERCEL_ORG_IDorVERCEL_PROJECT_ID. Someone with admin onSuede-AI/dnaneeds to add them under Settings → Secrets and variables → Actions, then run this workflow viaworkflow_dispatch.The difference after this PR is that until that happens, the workflow says so in red instead of green.
Expect the first run on
mainafter merge to fail. That is the point.🤖 Generated with Claude Code