search

rentpath / identity.js

Track a Universal RentPath Identity
2 stars 0 forks source link

chore: Modify deploy.js to deduce latest version in npm and use that version to build and deploy new libs to CDN #24

Closed martinstreicher closed 8 years ago

martinstreicher commented 8 years ago

A few questions about how this should work:

  1. This deploys to the CDN on AWS after a successful semantic release, which occurs only after tests run AOK. The code pulls the proper (latest) version number from npm (using npm view identity-rentpath versions to produce the proper file names.
  2. This works well in a controlled environment like Travis. However, if someone ran node deploy.js on a different branch locally, it could alter what is in the CDN, packaging a different commit and overwriting the latest release files in the CDN.
  3. I should likely change the code to not allow overwrites. However, this would not preclude mistakes such as (2) from being made.
  4. Of source, if the AWS keys are only in Travis, no one can alter AWS. Item (2) is moot, because nothing happens without the proper AWS creds.

Thoughts? @colinrymer @ripta @druidix @c0 @Teapane

colinrymer commented 8 years ago

Some thoughts/answers:

  1. The publish to S3 should happen along with the semantic-release (all of which should happen after all the tests pass, etc.) - I'm not a huge fan of making the release to S3 dependent upon NPM; if NPM is unavailable, we should still be able to publish to S3. We should investigate how we can get the version number without talking to NPM or GitHub.
  2. That could happen, but as you mention in 4, access to the keys will be significantly limited, such that the chances of someone deploying locally will be very slim and should only be happening in very specific cases (e.g. Travis is down and a deploy must happen within a certain timeframe).
  3. The publish to S3 code should not allow overwrites. If a version was incorrectly published, it should be removed, but we should not publish a corrected version of the same number; that should still require a version bump.
  4. AWS keys should/will be available to Travis in an encrypted format and stored in a password manager with limited access for exigent usage.
martinstreicher commented 8 years ago

Re: (1): The semantic-release process creates Github releases with the same version numbers. If the repo is up to date, as it would be in Travis, the last release tag is available and could be the basis of the next release. However, the whole semantic-release process itself seems dependent on npm and Github. So I am not sure tying S3 to npm and Github is all that much worse. That said, one could change the code to use the version attribute of package.json to release to S3. This is how it was done up til yesterday. So, one can publish manually to S3 — the code for deploy.js would have to be smart about npm and Github not being available and using package.json instead.

So, bottom line: version number is in the repo, if you have the latest version of the code.

Re: (3): I need to write some code to prevent overwrites.

On Mar 21, 2016, at 10:51 AM, Colin Rymer notifications@github.com wrote:

Some thoughts/answers:

The publish to S3 should happen along with the semantic-release (all of which should happen after all the tests pass, etc.) - I'm not a huge fan of making the release to S3 dependent upon NPM; if NPM is unavailable, we should still be able to publish to S3. We should investigate how we can get the version number without talking to NPM or GitHub.

That could happen, but as you mention in 4, access to the keys will be significantly limited, such that the chances of someone deploying locally will be very slim and should only be happening in very specific cases (e.g. Travis is down and a deploy must happen within a certain timeframe).

The publish to S3 code should not allow overwrites. If a version was incorrectly published, it should be removed, but we should not publish a corrected version of the same number; that should still require a version bump.

AWS keys should/will be available to Travis in an encrypted format and stored in a password manager with limited access for exigent usage.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/rentpath/identity.js/pull/24#issuecomment-199323793

colinrymer commented 8 years ago

Good point - given that semantic-release requires NPM and GitHub be available, using NPM to fetch the version info seems reasonable.

martinstreicher commented 8 years ago

OK, so my last task then is to prevent overwrites of existing versions.

On Mar 21, 2016, at 11:43 AM, Colin Rymer notifications@github.com wrote:

Good point - given that semantic-release requires NPM and GitHub be available, using NPM to fetch the version info seems reasonable.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/rentpath/identity.js/pull/24#issuecomment-199346283

martinstreicher commented 8 years ago

This is ready for review. @ripta @colinrymer

Teapane commented 8 years ago

:+1: