Auto-publish Chrome extensions

[paulmolluzzo]

Taken from this comment.

For GitHub repos that are Chrome Extensions, it would save time to have a micro app that connects your Google Developer Account and your GitHub account that auto deploys a ZIP of the extension when it's tagged with a release (or there's a push to master).

Some thoughts/notes:

• Using the Web Store API you'll need to get authorization from the User to POST to their account, and you'll need the $APP_ID of the extension in question.
• If the GitHub repo is public, you can probably avoid OAuth for the User and just provide an endpoint for a webhook. If you tie into the releases event you would need the path to the ZIP of the extension. If you want to support private repos then you'll need OAuth for the GitHub side too.
• All extensions will need to have a ZIP in the repo, which is sometimes ignored with git. Another option is to assume the entire repo is the extension and grab the zipball_url from the event payload, but I don't know if there are a lot of repos with a structure that supports it.

[sindresorhus]

All extensions will need to have a ZIP in the repo

Or support an option that let's you specify the relative path to the directory containing the extension. For refined-github it would be extensions.

[paulmolluzzo]

Or support an option that let's you specify the relative path to the directory containing the extension. For refined-github it would be extensions.

Yes, that could work, but then the app would need to determine if the path is a ZIP or directory, and then ZIP any directory. But I agree, this idea is ideal and most flexible.

[sindresorhus]

@paulmolluzzo No, it would just unzip the zipball_url and then re-zip the specified subdirectory.

[paulmolluzzo]

@sindresorhus what if you "point" to a ZIP file somewhere inside the repo?

[sindresorhus]

@paulmolluzzo It should only support pointing to a directory.

[Qix-]

@paulmolluzzo build artifacts should never be in a repository.

[paulmolluzzo]

It should only support pointing to a directory.

build artifacts should never be in a repository.

I agree with both, but not everyone follows these rules. Just sayin'.

[sindresorhus]

I agree with both, but not everyone follows these rules. Just sayin'.

Then they simply can't use the webapp.

[Qix-]

@paulmolluzzo then they're doing a disservice to people who use git ;) Build artifacts cause de-synchronized code bases, confusing/oftentimes wrong releases, and huge cloning overhead (namely because they're usually packaged, thus creating large objects that get tracked and change all the time).

Plus they're dangerous, as someone can discreetly introduce security vulnerabilities or malicious exploits that would otherwise go unnoticed due to the usually obfuscated/obscure nature of build artifacts.

But I digress. /rant

[paulmolluzzo]

Guys, I'm not disagreeing with either of you, I'm just giving the other side of the coin. Whoever builds this can make the decisions and deal with the users themselves.

Re: ZIPs - probably not too likely to be a big issue, so long as the app ZIPs up the directory.

Re: complete builds - anyone who compiles into a dist is going to have an issue, unless the app also builds everyone's src. As an example, this repo would not be able to use the app unless you plan to run npm scripts: https://github.com/DrewML/refined-github/

In the end it's not really up to me what happens anyway.

[forivall]

Can travis do this (building, etc)? It's already being used for semantic-release.

[Qix-]

Probably can.

[fregante]

Recently I found this but I never tried it: https://github.com/robertknight/extension-tools/blob/master/src/publish-chrome-extension.js

Also this one was similar but it might need to be extracted from grunt https://github.com/c301/grunt-webstore-upload

[paulmolluzzo]

I built a fake extension just to get a working POC using the https://github.com/c301/grunt-webstore-upload that @bfred-it suggested. It's actually working pretty nicely, so long as you don't mind some up front config.

I documented it a bit, but I might have missed a step some place along the way.

Repo that is auto-deploying here: https://github.com/paulmolluzzo/test-deploy-chrome

Chrome extension here (it console.log the version number): https://chrome.google.com/webstore/detail/test-deploy-chrome/gppbnpldokpcchfpckfdoiaeboinfldm

I'm pretty satisfied with this solution, but welcome suggestions for improvements.

[paulmolluzzo]

Found this but have not tried it: https://www.npmjs.com/package/chrome-extension-deploy

[fregante]

Also this: https://github.com/DrewML/chrome-webstore-upload

[fregante]

This can be closed since chrome-webstore-upload and chrome-webstore-upload-cli work great!