Repository navigation
Publish our extensions to our own store, from CI - #125
Merged
Merged
Conversation
We built a store with one-click install and Chromium auto-update -- crx.ts stamps our update_url into the manifest before signing, precisely so Chromium polls /api/store/updates.xml rather than Google. Then every listing was created by hand, which in practice meant almost none were: the store holds exactly one extension, and our own MarkSyncr is not in it. That is the gap worth closing. An extension in the store auto-updates for anyone who installed it. An extension outside the store reaches TronBrowser only by being rebuilt into the bundle, and reaches everyone else only when Google approves it. MarkSyncr has three releases sitting in Chrome review right now. So publishing runs from CI. scripts/store-publish.mjs resolves the listing by slug, creates it on first run, and posts the version with the manifest and the artifact URL. The reusable workflow wraps it so an extension repo adds six lines rather than its own half of the job. Two behaviours worth stating. A version that is already published exits clean instead of failing, so re-running a tag is safe. And the artifact is polled before submitting, because the store fetches it itself and a release asset can lag its tag by a few seconds -- submitting into that window fails for a reason that has nothing to do with the extension. Verified against the live store: an existing listing resolves by slug (coinpay-wallet), an unknown name takes the create path, and a manifest that is not MV3 is refused before anything is sent. Nothing publishes until TRONBROWSER_STORE_TOKEN exists. The API deliberately refuses to mint a publisher token from a token -- it has to come from a signed-in browser session -- so that one step is Anthony's and cannot be automated away. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
ThreatCrush Security Scan52 finding(s) HIGH/CRITICAL: 3 | MEDIUM: 28 | LOW: 21
…and 2 more. Full results in the Security tab. Snippets are redacted; ThreatCrush never prints matched credential material. |
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
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.
Publish our extensions to our own store, from CI
We built a store with one-click install and Chromium auto-update -- crx.ts
stamps our update_url into the manifest before signing, precisely so Chromium
polls /api/store/updates.xml rather than Google. Then every listing was created
by hand, which in practice meant almost none were: the store holds exactly one
extension, and our own MarkSyncr is not in it.
That is the gap worth closing. An extension in the store auto-updates for anyone
who installed it. An extension outside the store reaches TronBrowser only by
being rebuilt into the bundle, and reaches everyone else only when Google
approves it. MarkSyncr has three releases sitting in Chrome review right now.
So publishing runs from CI. scripts/store-publish.mjs resolves the listing by
slug, creates it on first run, and posts the version with the manifest and the
artifact URL. The reusable workflow wraps it so an extension repo adds six lines
rather than its own half of the job.
Two behaviours worth stating. A version that is already published exits clean
instead of failing, so re-running a tag is safe. And the artifact is polled
before submitting, because the store fetches it itself and a release asset can
lag its tag by a few seconds -- submitting into that window fails for a reason
that has nothing to do with the extension.
Verified against the live store: an existing listing resolves by slug
(coinpay-wallet), an unknown name takes the create path, and a manifest that is
not MV3 is refused before anything is sent.
Nothing publishes until TRONBROWSER_STORE_TOKEN exists. The API deliberately
refuses to mint a publisher token from a token -- it has to come from a signed-in
browser session -- so that one step is Anthony's and cannot be automated away.
Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com