Let CI do every release after the first one - #71
Merged
Merged
Conversation
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 Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
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.
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.ymldoesOn a published release: downloads that release's zip, uploads it, publishes it.
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.
CWS_EXTENSION_IDCWS_PUBLISHER_IDCWS_SERVICE_ACCOUNTTwo things that will otherwise be learned the hard way
versions agreecheck 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/authSHA resolves to thev3.0.0tag rather than the movingv3. zizmor clean.Not yet run: it cannot be until the item and the secrets exist.
gh workflow run store.yml -f tag=v0.5.0uploads without publishing, which is the first real test.