Extension channels: dev and main each carry their own signed extension #237
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: bvandeusen/FabledCurator#237
Reference in New Issue
Block a user
Milestone 271, complete — plus the review-pass batch that preceded it.
What changes for an operator
devandmaineach build, sign and bundle their own extension. Trying an extension change no longer requires merging to main, which is what rules 146/147 name as testing by shipping.One AMO signature per extension change, shared by both channels. The version is the commit time of the newest packaged-extension change (family rule 149 — never a commit count, which orders by branch rather than by recency), so both branches derive the same number for the same source.
devsigned1.0.3500147; this merge should findext-1.0.3500147already cached and bundle the byte-identical XPI into:latestwith no second AMO call. Worth eyeballingsign-extension's cache step on the main build — that property is what makes two channels affordable, and this is its first cross-channel test.Merge with a merge commit, not squash or rebase. Both rewrite the committer date, so main would derive a higher version than dev, miss the cache, and burn a second signature for identical code. Verified against existing history:
origin/mainand the dev commit it merged both derive1.0.3465860, because the merge commit is TREESAME on the extension pathspec and so is never the newest listed commit.The channel is reported beside the version, never inside it —
/api/extension/manifestgains an optional"channel", and the popup, toolbar tooltip and Settings card name it. A-devsuffix would collapse under the comparator'sparseInt, making every dev build compare equal.Contents
Milestone 271 — extension channels
cd5444ederive the version from commit time, not commit count (#3092)239b1edbuild:devimages again so the dev channel can carry a build5447a40the derived version drives signing (step 4)9eb946bsign on dev too, bundle the XPI into:dev(step 6)fe48e77retire the manual-bump guard, true up the docs (step 5)a7e626areport the channel beside the version (step 7)0db38cclog in to the registry with the docker CLI, notdocker/login-action(#3118)Review pass (#3066–#3072)
39cf81aclear an artist's attachments before the cascade delete2ce467eartist cascade preview counts posts and attachments2e0f8f8reclaim orphaned attachments — rows and store blobsddf8960516521eretire deviantart end-to-end8915547cover the Layer-2 auto-refetch remediationbfc5135true up README1ac448d5a0e1bbfour small cleanups + batch the auto-apply sweeps' image_tag insertsVerification
CI green on
0db38ccfor lint, extension-version, backend unit, frontend build, integration, and the extension lint/vitest/XPI-content lane.One caveat, carried knowingly:
build-agentwent red on that run after its push completed — all layers pushed (#14 DONE 179.9s) and the registry showsfabledcurator-agent:devwritten at 16:19:44, then buildx failed resolving the tag in the local daemon. The artifact is correct; the lane is not. Filed alongside #3118, which is the same family of problem: concurrent jobs sharing per-runner state.Known follow-ups
build-agentalternated 7s and 10m13s on byte-identical source. Registry-backed cache is the fix, and it is the operator's next piece of work.Executes the 2026-07-05 product decision (FC downloaders = art-dedicated services only), which removed Twitter/X and Bluesky but left deviantart fully wired for seven weeks — the half-retired state rule 22 exists to prevent. Removed: the PlatformInfo module and its registry entry, the gallery-dl extractor block, extension_service's artist-page pattern, the extension's PLATFORMS + PLATFORM_ARTIST_PATTERNS entries, its manifest host permission and content-script match, the frontend icon/colour/label, and the operator- facing "supported platforms" list that still advertised it. Two judgment calls, both recorded in migration 0088: * existing `source` rows are DISABLED, not deleted. The row is the only record of the artist's DeviantArt URL. Disabling is also required for correctness rather than tidiness: with the platform unregistered the download path falls through to gallery-dl, which carries its OWN deviantart extractor, so an enabled row would have kept downloading from a dropped platform. * the `credential` row IS deleted — a live session cookie for a site FC will never call again. Adds the invariant whose absence is why manifest.json drifted in the first place: nothing tied its domain lists back to the platform table. The extension suite now asserts both directions, plus that no host permission belongs to an unclaimed domain (`*://*/*` exempted — FC is self-hosted at an operator-chosen URL the extension cannot enumerate). Extension version 1.0.10 -> 1.0.11: ci.yml's guard hard-fails a packaged extension change without a bump. No release is cut — build.yml's sign-extension job only runs on main. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>refetch_service was the only module under backend/app/services/ with no test file — and not an inert one: it runs unattended off the recovery sweep and deletes a file from disk before asking a downloader to replace it. The frontend cites it by name as the reason the Import tab could be retired ("imports heal themselves"). The ticket described it as having zero direct coverage. That is true of the module, but not of the code: test_api_import_admin.py already drives the happy path end-to-end through the refetch route — file deleted, task flagged, one dispatch, second attempt a no-op. These 17 tests therefore target what the route tests cannot reach rather than restating them: * every branch of resolve_refetch_source — disabled Source, a `sidecar:<platform>:<slug>` synthetic anchor, a platform mismatch, the gallery-dl `NN_` numbering-prefix sidecar, the lowest-id pick among several candidates, and each of the five ways it declines (no sidecar, unreadable JSON, non-object JSON, no platform, no artist folder / no matching Artist row). * that the file SURVIVES when nothing re-pollable resolves. This is the assertion the module exists for: `no_source` is the common case on a filesystem-only library, where the file on disk is the operator's only copy. The route-level no_source test cannot catch a regression here — its path never existed, so an unconditional unlink would pass it. * that the `refetched` bound is checked BEFORE the unlink, so a second sweep leaves the re-downloaded file alone rather than deleting it again. * that an unlink failure is logged and stepped over, not raised — a raise would abort the whole sweep for every other poison-pill row in the batch. Exercised with a real IsADirectoryError rather than a patched pathlib. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>build.yml triggered on main and tags only. The 2026-05-26 comment gave the reason: "operator tests from :latest after merge-to-main, not from the dev branch image. Saves one full docker build per dev push." That trade has since been named as a fault. Family rule 147 — main IS production, test on :dev, never by shipping — and rule 146 — a rolling channel refreshes itself, and a channel that can only be refreshed by shipping is not a channel. 146's note on 147 describes this exact shape: the pressure to test by shipping does not come from carelessness, it comes from :dev being unable to carry the build. Two live consequences, not hypotheticals: - docker-compose.yml pins fabledcurator:dev, an image nothing has published since May. The registry-image path of the documented quick-start could not have worked. - trying an extension change required merging to main, because sign-extension is gated to main and :dev did not exist to carry an XPI. Shipping was the only way to test. All three images build on dev. Deliberate: a :dev web image paired with a stale :dev ml or agent is a worse trap than no dev channel, because the mismatch surfaces as a runtime failure rather than a missing tag. The cost the 2026-05-26 note was avoiding is real and is now paid on every dev push — layer reuse should keep ml's cost to the COPY layers, but if it bites, narrowing is a `paths:` filter away. :dev only. The dev path never writes :c-<sha>: that is the rollback unit (rule 145), and a rolling tag may legitimately carry newer contents than the :c-<sha> of the same commit. This does NOT yet put an XPI on :dev — sign-extension is still gated to main, and ungating it has to wait for the derived version to control publishing, or dev would sign the hand-set 1.0.11, hit the existing cache and ship main's stale XPI. That is the next step.Closes the half of the ask the signing work didn't: a way to tell a dev build from a main one. FC_CHANNEL is baked into the web image at build time and /api/extension/manifest reports it as its own key, next to version — the popup banner, the toolbar tooltip and the Settings card all name it. Beside the version, never inside it. A `1.0.3499884-dev` suffix is the obvious shortcut and it is the exact failure this design comes from: versionIsNewer parses each dotted segment with parseInt, so a suffixed segment reads as 0, every dev build compares equal to every other, and "no update available" stops being distinguishable from "I cannot read this version". The comparator already degrades rather than discarding (rule 150), which is a reason not to NEED the suffix, not a licence to add one. Two tests hold the line — one backend, asserting version and channel are separate keys; one frontend, asserting the rendered version text stays the bare derived number. Optional on the read side, and absent rather than defaulted. An image built before this field says nothing by not having the key; an image built without a channel now says nothing the same way, so there is one absence to handle instead of a second spelling of "unknown". Every reader drops the label entirely when it is missing and reads exactly as it did before. Reported verbatim rather than validated against {dev, main}: if an image declares something else, showing what it claims helps whoever is debugging more than dropping it would. FC_CHANNEL is declared LAST in the Dockerfile. An ARG invalidates every layer below it, and this is the one value that differs between the dev and main builds of identical source — earlier, and the two channels could never share a cached pip install. A tag push counts as main: a vYY.MM.DD tag is cut from main, so that image is a main-channel artifact wearing an immutable name. No channel switcher, deliberately. background.js:34 already records that Firefox's static update_url cannot apply, because every FC instance is a different host — so the extension asks its configured backend, and the channel IS the instance it points at. Switching is repointing apiUrl and reinstalling from that host. A separate setting would contradict each server build shipping its own extension. This commit touches packaged extension files, so it moves the derived version and will sign a new one via AMO — the first push to exercise the extension-changed path from dev end to end.