Skip to content

Let CI do every release after the first one - #71

Merged
sotashimozono merged 1 commit into
mainfrom
store-from-ci
Sep 15, 2026
Merged

sotashimozono merged 1 commit into
mainfrom
store-from-ci

Conversation

@sotashimozono

Copy link
Copy Markdown
Member

souta registered the developer account and asked whether CI could take it from here. Mostly yes, and the line is not where you would guess.

What the API cannot do

It cannot create a listing. Description, screenshots, category and the data disclosure are not reachable from it, and the extension ID does not exist until the Store listing and Privacy tabs have been filled in by a person. So the first submission is by hand and always will be.

Every update after that is a package upload and a publish, and both are API calls.

What store.yml does

On a published release: downloads that release's zip, uploads it, publishes it.

POST https://chromewebstore.googleapis.com/upload/v2/publishers/{PUBLISHER}/items/{ITEM}:upload
POST https://chromewebstore.googleapis.com/v2/publishers/{PUBLISHER}/items/{ITEM}:publish

The human gate is not removed, it moves — merging the release PR is the decision — and what reaches the store is the package that was built, tested and attached to the release rather than one dragged into a browser.

A service account, not a refresh token

A refresh token issued while the OAuth consent screen is still in "Testing" expires after a week, so the pipeline would work today and fail next month having changed nothing. v2 takes service accounts, which do not expire. One JSON key in a secret; the dashboard takes the account's email under Account.

Three secrets, and the job refuses before authenticating when one is missing, naming which. An authentication error twenty lines into a log is the same fact told worse.

secret source
CWS_EXTENSION_ID the item's dashboard URL, once it exists
CWS_PUBLISHER_ID Developer Dashboard → Account
CWS_SERVICE_ACCOUNT the service account's JSON key

Two things that will otherwise be learned the hard way

  • The API does not set visibility. An item whose visibility was changed by hand must be published by hand once before the API will do it again.
  • A version cannot be uploaded twice — which is what the versions agree check has been protecting all along.

Endpoints and the service-account flow are from the Chrome for Developers documentation rather than memory. The google-github-actions/auth SHA resolves to the v3.0.0 tag rather than the moving v3. zizmor clean.

Not yet run: it cannot be until the item and the secrets exist. gh workflow run store.yml -f tag=v0.5.0 uploads without publishing, which is the first real test.

souta registered the developer account and asked whether CI could take it from
there. Mostly yes, and the line is not where you would guess.

The Chrome Web Store API cannot create a listing. Description, screenshots,
category and the data disclosure are not reachable from it, and the extension ID
does not exist until the Store listing and Privacy tabs have been filled in by a
person. So the first submission is by hand and always will be. Every update
after it is a package upload and a publish, and both are API calls.

`store.yml` does those on a published release. The human gate is not removed, it
moves: merging the release PR is the decision, and what reaches the store is the
package that was built, tested and attached to that release rather than one
dragged into a browser.

A service account rather than a refresh token. A refresh token issued while the
OAuth consent screen is still in "Testing" expires after a week, so the pipeline
would work today and fail next month having changed nothing. v2 of the API takes
service accounts, which do not expire; the JSON key is one secret and the
dashboard takes the account's email under Account.

It refuses before authenticating when a secret is missing, and names which. An
authentication error twenty lines into a log is the same fact told worse.

Two things the docs say and experience will otherwise teach: the API does not set
visibility, so an item whose visibility was changed by hand must be published by
hand once before the API will do it again; and a version cannot be uploaded
twice, which is what the `versions agree` check has been protecting all along.

The endpoints and the service-account flow are from the Chrome for Developers
documentation rather than memory, and the action SHA resolves to the v3.0.0 tag
rather than the moving `v3`.

Signed-off-by: Souta <shimozono-sota631@g.ecc.u-tokyo.ac.jp>
@codecov

codecov Bot commented Sep 14, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

@sotashimozono
sotashimozono merged commit a2be1f7 into main Sep 15, 2026
18 checks passed
@sotashimozono
sotashimozono deleted the store-from-ci branch September 15, 2026 03:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant