search

kyrofox / iceproject

A browser extension created by the Imgur Community for use on imgur.
23 stars 9 forks source link

Deployment Question #8

Open GrimTheReaper opened 8 years ago

GrimTheReaper commented 8 years ago

So, I figured that code pushed to the repository won't automagically appear in the chrome web store or appear in an extension update, which leads me to guess that your current plan is to manually push the different versions? If this is the case, I recommend setting up either a CircleCI or a TravisCI automation (this would also be good for enforcing test for any PR) and possibly have it push to the chrome web store if a certain branch is updated. For instance, we could have a "prod" branch that when code is pushed signals an update. Also, since this is an open source project it should be free for us to do this.

Willsr71 commented 8 years ago

I have a Jenkins that could be provided if need be. One potential issue with this is that if a commit breaks something it would get pushed anyway. It might be better to take advantage of Github Releases (have a script that takes the latest release and pushes it to the store)

GrimTheReaper commented 8 years ago

@Willsr71 that would work as well. But the point of a CI is to also test to make sure that a commit doesn't break anything. I just want to make sure going forward we have a deployment path that works well.

Willsr71 commented 8 years ago

Jenkins can do that as well, but the thing is there is no easy way to automatically test a chrome extension (that I can think of anyway).

GrimTheReaper commented 8 years ago

There are many different things to test for though. Also, no offense but it would be better to use a CI that is owner neutral (such as CircleCI or TravisCI, or a Jenkins owned by the repository owner) so that security and file integrity can be assured.

Willsr71 commented 8 years ago

None taken. I'm just more of a Java person and Maven has integrated testing wheras with JavaScript there is no easy way to automagically test things on websites.

GrimTheReaper commented 8 years ago

Yeah, I'm with you there. :stuck_out_tongue: But there still are things to test, such as syntax.

Willsr71 commented 8 years ago

Indeed. One thing we could do is create a separate script that runs various functions in the extension and checks for expected output but that would still only go so far.

HoverBaum commented 8 years ago

I actually feel a CI would go overboard. Or at least be something that should be considered later. As this is also meant as a learning experience. Might be a bit rambly here.

I am currently writing up a Pull request to organize files into folders and add Gulp as a taskrunner to created minified files and a .ZIP for the maintainer to upload to the store.

And actually can you push to the Chrome store through some sort of API? Would look into this but am currently in China.

I actually like @Willsr71 idea of using releases here on GitHub (haven't worked much with them) but that also seems to be an improvement on keeping a history.

Willsr71 commented 8 years ago

@HoverBaum In answer to the webstore API question, https://developer.chrome.com/webstore/using_webstore_api

For the releases the only thing that needs to be done is a tag for each version of the repository that would be considered a release and then when a release is created github will automatically include a zip of the repository from the tag. In addition you can provide descriptions and the zip file created by gulp, etc.

HoverBaum commented 8 years ago

I feel like we shouldn't think about a Continuous Integration (CI) for now. As that would require at least unit testing the entire code.

It seems to me that manual releases will be best for now. Maybe tags on GitHub.