How to perform Google Add-on automated unit testing and publishing with Circle CI — Part 3
This is part 3 of our CI/CD for Google Addon series, if you miss them you can find the first two parts here :
In the first part of our series, we manually published our add-on on the chrome web store. In this part we will setup our CI to manually publish when a new commit is pushed on our production branch, by using the Chrome Web Store API : https://developer.chrome.com/webstore/using_webstore_api
Though the nodejs client supports a lot of libraries https://github.com/google/google-api-nodejs-client/tree/master/src/apis it does not seem to support the Chrome Web Store API yet, so we will have to make the REST calls ourselves.
Notably, this implies that we will have to refresh our token manually. The script below shows an example of getting a fresh token using a refresh token :
To publish and update an add-on on the chrome store, you need to upload an archive file. It must contain various files including the manifest : https://developer.chrome.com/apps/manifest
Normally when you publish a chrome extension you need to include the javascript code in the archive. In our case, since we deployed the code already we can simply reference it from the manifest with the script version number.
When we first published the add-on in part 1, a manifest file was automatically created for us by the script.google service. You can retrieve it from the chrome web store dashboard (more infos, download main.crx)
Download the .crx file and change the extension to .zip, then decompress it. Ignore the possible warnings. You will find various files including the manifest file manifest.js which should look similar to this :
Notice the version number : we will want to increase it every time we publish. The container_version variable correspond to our deployed version number.
This is why we do not need to include the code in the archive, the code is already referenced by the manifest version number.
In short, all we need to do is :
- create and deploy a new version of the script
- update the archive manifest with the new version number
- zip the archive folder
- upload the archive to the chrome store
- publish the updated version of the application
You can see the final version of the code with all the steps here : https://github.com/Effilab/HelloAddon/blob/master/deploy.js
We use clasp versionto create a new numbered version (think of it like a git commit sha, which references the code at a specific point in time) and clasp deploy to deploy this new version (don't get confused between deploy and publish terminology, we “deploy” the code and “publish” the addon on the store)
Here is the call to upload the archive. The APP_ID is the application id we determined at the end of Part 1 (it is a part of the add-on url). The ARCHIVE_NAME is the path to the zipped archive folder containing the manifest and the icons.
The deploy part of the CI looks very similar to the test part, except we only execute it on the production branch :
Contrary to the TEST_* credentials, the PROD_* credentials must have the https://www.googleapis.com/auth/chromewebstore scope to be able to publish on the web store.
You can generate the credentials by calling the authenticate() function we previously defined :
Conclusion
Our CI is finally ready : we have automated tests to warn us during the development, and automated publishing once we push on the production branch.
Overall we found that app scripts development was really enjoyable, but it is still lacking some tooling to make the process easier. We wish that app scripts would include all the Gast helpers for testing for instance, as well as mocking/http recording capabilities. We could also imagine a clasp publish command that would publish on the chrome web store for us.
Until then, we hope this article can help you setup a satisfying apps script develoment workflow.
