aws-builds.ymlfix(deploy): keep staging's sitemap absolute, and stop advertising a dead override
Two problems Greptile caught in the previous commit.
Staging resolves to an empty marketing origin, and exporting that as
VITE_PUBLIC_MARKETING_URL did not collapse to the app origin the way it reads: the
SEO plugin falls back with ??, which preserves an empty string, so staging would
have emitted `Sitemap: /sitemap.xml` and `<loc>/pricing</loc>` — relative URLs a
sitemap cannot use. Only export the variable when it is non-empty, and fall back
in vite.config.ts on falsy rather than nullish so an empty value can never win.
site-config.ts already used || and was unaffected, which is why the canonical
stayed correct while robots/sitemap would not have.
The prod validation build also named CEDAR_AWS_PROD_MARKETING_URL as its override,
but nothing reads that variable any more — the publisher resolves the origin from
cedar_marketing_url_for_env. Source that helper instead so the validation build
cannot drift from what actually ships.
Co-Authored-By: Claude Opus 5 (1M context) <<email>>Aug 30, 2026, 10:52 PMci.ymlci(server): six shards and 25 minutes, so the ceiling stops deciding
Two shards failed on this PR with no failing test in either — "The operation was
canceled" at 15m17s, which is `timeout-minutes` and not a result. At four shards
the suite had grown to where a shard lands anywhere between 10 and 15 minutes
depending on which runner it draws, so the same commit passed or failed on runner
luck: shard 1 took 10m49s on one run and 13m14s on the next, shard 3 went 12m35s
then over.
Six shards put a shard back around 7-10 minutes and cut wall-clock time to a
verdict; the raised timeout is headroom above that, so a slow runner costs
latency rather than a red check. The cost is 50% more runner minutes per PR,
which is the trade being made deliberately.
Neither number is a budget to fill. A shard creeping back toward 25 minutes means
the suite wants splitting again, not a bigger ceiling — the comment says so where
somebody will read it.
Co-Authored-By: Claude Opus 5 (1M context) <<email>>Sep 10, 2026, 10:02 PM1 defectdesktop-release.ymlfix(ci): guard dispatch ref and make the release lookup fail closed
Addresses two problems introduced by the previous commit.
workflow_dispatch accepts an arbitrary ref, and any ref that is not `staging`
was treated as production. A dispatch on any branch would therefore check that
branch out and run its build scripts with the signing, notarization, update-key,
and publishing secrets. Refuse any ref other than main/staging as the first step
of `check`, before a secret is referenced; `release` needs `check`, so the macOS
job never starts.
The release lookup was still fail-open: `gh release view` failing for any reason
was read as "release does not exist". A transient 5xx, rate limit, or network
error would start a redundant macOS build and re-upload over the assets of an
existing release. Only a definitive `HTTP 404` now means absent; auth failures
report what to fix, and anything else retries three times and then stops rather
than guessing. The write-access probe moved to run only when a build is actually
about to start.
Co-Authored-By: Claude Opus 5 (1M context) <<email>>Aug 29, 2026, 10:57 AM1 defectdesktop-version-check.ymlfix: linter and ci/cd workflowFeb 28, 2026, 8:50 PMprod-deploy.ymlfix(ci): forward CEDAR_MCP_PUBLIC_URL into the deploy workflows
Another link in the same chain Greptile's P1 caught: buildEnvironmentConfig
reads CEDAR_AWS_{STAGING|PROD}_MCP_PUBLIC_URL from process.env at CDK-synth
time, but the GitHub Actions deploy-backend jobs only forward an explicit
allowlist of vars.* into that process — this one wasn't in it, so setting the
GitHub environment variable alone still wouldn't have reached a real deploy.
Both are unset by default (matching every other var in this allowlist), so
this is a no-op until the corresponding GitHub environment variable is
actually set ahead of the Manufact domain cutover.
Co-Authored-By: Claude Sonnet 5 <<email>>Sep 18, 2026, 9:22 AMstaging-deploy.ymlfix(ci): forward CEDAR_MCP_PUBLIC_URL into the deploy workflows
Another link in the same chain Greptile's P1 caught: buildEnvironmentConfig
reads CEDAR_AWS_{STAGING|PROD}_MCP_PUBLIC_URL from process.env at CDK-synth
time, but the GitHub Actions deploy-backend jobs only forward an explicit
allowlist of vars.* into that process — this one wasn't in it, so setting the
GitHub environment variable alone still wouldn't have reached a real deploy.
Both are unset by default (matching every other var in this allowlist), so
this is a no-op until the corresponding GitHub environment variable is
actually set ahead of the Manufact domain cutover.
Co-Authored-By: Claude Sonnet 5 <<email>>Sep 18, 2026, 9:22 AM