2 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
Claude	c37a180c3c	ci: guard the extension publish path against a missed version bump ... build.yml's sign-extension keys its AMO-signing cache purely on the version string in extension/package.json. If an ext-<version> release already has an XPI, signing is skipped and build-web bakes that OLD signed XPI into :latest. Nothing in that path inspects whether extension/ actually changed, so a forgotten bump ships a stale extension on a fully green build -- silently, and as the default outcome of forgetting. AMO can't backstop it either: it 409s on re-signing a version, which is precisely why the cache exists. New extension-version job, pure git + text, no deps or services: 1. Unconditional consistency check. manifest.json and package.json versions must match. web-ext sign reads manifest.json (package.json is in --ignore-files and isn't even inside the XPI), so AMO signs the manifest version; build.yml keys its cache, release tag, XPI filename -- and so the version /api/extension/manifest reports to the update prompt -- on package.json. Divergence either 409s at AMO or ships an XPI whose update prompt lies about what's installed. 2. Changed-without-bump check. If any PACKAGED file under extension/ differs, the version must have moved. Exclusions mirror --ignore-files so a Renovate web-ext devDep bump in package.json doesn't falsely demand one. Compared against main rather than the previous push: the publish decision is made at merge-to-main against whatever ext-<version> exists, so "differs from main" is the question that matters. Diffing against the previous dev push would demand a fresh bump on every iteration, inflating the version to buy nothing. Bumping stays manual -- making it automatic requires rewriting the version in CI and committing back to a protected branch, which this workflow deliberately avoided. This only ensures a missed bump can no longer be silent. Refs #2393 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-02 20:20:44 -04:00
Claude	8214afee1e	fix(extension): normalize FC URL so credential push doesn't 405 ... The stored apiUrl was required to already carry the `/api` suffix, since api.js builds requests as `${baseUrl}/credentials`. The options label read "FC base URL", so entering the instance root -- the natural reading -- sent every request one path segment short: POST /credentials hit the Vue SPA catch-all and came back 405, and GET /extension/manifest 404'd. Worse, Test Connection reported success on it: the catch-all answers GET /credentials with 200 HTML, so `r.ok` was true and the only affordance meant to catch this misconfiguration actively masked it. Normalize instead of validate (rules 92, 26): - New lib/url.js: normalizeApiUrl / webRootFromApiUrl, one source shared by the background client and the options page. Accepts either the instance root or the API root. - api.js normalizes on read, so configs already stored in the broken form heal themselves without the operator reopening Settings. - options.js stores the canonical form, echoes back what it saved, and the test now asserts a JSON content-type -- killing the false green. - 404/405 in request() now names the URL and points at the setting. - Options label/placeholder state that both forms work. Version 1.0.9 -> 1.0.10 in BOTH manifest.json and package.json; build.yml resolves the release version from package.json, and a stale value there would hit the cached ext-1.0.9 asset and republish the old XPI unsigned against the new code. Refs #2393 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-02 19:37:38 -04:00