CWS Publish

NPM package that can be used with CI to publish extensions at Chrome Web Store.

This package lets you upload chrome extensions (.zip) to Chrome Web Store using continuous integration.

This packages has been used successfully with travis CI and gitlab CI, but should work with any CI environment that allows you to run node modules.


Table of Contents
  1. Usage
  2. Parameters
  3. Advanced Usage
  4. Random Notes

1 Usage

1. Add package to your project

npm install --save-dev cws-publish


2. Choose your upload behavior

There are 3 available options:

A. Upload extension as a draft
B. Upload and publish extension immediately
C. Upload and publish extension to testers (iff your extension is currently NOT published)


3. Configure your upload behavior:

A) upload as a draft - manual publish from developer console is still required:

npx cws-upload $client_id $client_secret $refresh_token ZIP_FILE EXTENSION_ID

B) immediate release:

npx cws-publish $client_id $client_secret $refresh_token ZIP_FILE EXTENSION_ID

C) immediate release to testers:

npx cws-publish $client_id $client_secret $refresh_token ZIP_FILE EXTENSION_ID --testers



2 Parameters

Obtaining Google API Credentials

$client_id, $client_secret, $refresh_token

Detailed instructions for obtaining these values are explained in this guide: https://developer.chrome.com/webstore/using_webstore_api#beforeyoubegin

The general process is:

  1. Enable Chrome Web Store API in Google API Console
  2. Create OAuth Credentials in Google Console - this will generate $client id and $client_secret
  3. Authorize Chrome Web Store API - from here you get the $refresh_token

Once you have $client_id $client_secret and $refresh_token save them as environment variables in you CI project settings. **NEVER share these values with anyone or commit them to your repository!**


Obtaining <ZIP_FILE>

Generating a zip file is outside the scope of this package. It is assumed that you have already generated a zip file during previous build steps. Please see for example gulp-zip for instructions if necessary.

Once you know the location of the zip file, update the upload/publish command and replace <ZIP_FILE> with path to file.

EXAMPLE: if the zip file is my.zip in a directory called build, the upload command would now look like this:

npx cws-upload $client_id $client_secret $refresh_token ./build/my.zip EXTENSION_ID


Obtaining <EXTENSION_ID>

Go to chrome web store developer console and click “More info”. Copy the item id (approx. 32 character string) and paste it to your upload/publish command to replace <EXTENSION_ID>.

EXAMPLE: if your extension id is fpggedhgeoicapmcammhdbmcmngbpkll, the upload command would now look like this:

npx cws-upload $client_id $client_secret $refresh_token ./build/my.zip fpggedhgeoicapmcammhdbmcmngbpkll

This completes the configuration steps.

If you want to see some real-life examples of configuration, please see these repositories.



3 Advanced Usage Ideas

Deploy based on some condition, such as only on tagged commits.

The general idea is to use the same command, but run the command based on conditional check

Travis CI example

- if [ ! -z  "$TRAVIS_TAG" ]; then 
      npx cws-upload $client_id $client_secret $refresh_token ZIP_FILE EXTENSION_ID 
  fi

Gitlab CI example

store_publish:
  stage: publish
  script:
    - npx cws-upload $client_id $client_secret $refresh_token ZIP_FILE EXTENSION_ID 
  artifacts:
    paths:
      - ZIP_FILE
  only:
    - tags

To keep your CI configuration file clutter free, you can use environment variables for all parameters:

npx cws-upload $client_id $secret $token $zip_path $ext_id



4 Random Notes

Q1: Can I use an API key to access chrome web store API?

This would be super easy to set up and ideal for CI, but the answer is no. See for example API Keys. When dealing with private user data simple access key will not suffice.

Q2: Can I use service account to access chrome web store API?

This would also be great for CI, but the answer is it depends. You can set up service account. You can get the necessary access tokens, but you can only impersonate a developer user if you are using G suite business account. Since that costs money and I don’t have such account I was unable to test this but supposedly it works for G suite users. If your google developer account is a regular gmail account then no you cannot use service account here. This ultimately leaves us with doing the oauth 2.0 dance to obtain the necessary credentials. It is quite a mess but luckily you only need to do it once.

Q3: Can I use same credentials across multiple extension projects?

Yes

Q4: What CI providers is this compatible with?

Travis-CI; possible others as long as they support Node

References

License

MIT