Publish with Travis CI

[eliangcs]

Allows to publish npm packages from Travis CI. The process is going to be like:

1. Run yarn bump locally and select the versions to bump
2. Git tag PACKAGE_NAME@VERSION for each package (e.g. zapier-platform-cli@8.2.1 and zapier-platform-core@8.2.1) is pushed to GitHub
3. Travis sees the git tag and runs scripts/publish.sh, which publishes a package to npm registry
4. In the case of publishing zapier-platform-core, a postpublish hook is configured to build and upload the boilerplate to S3

[eliangcs]

We'll probably need to re-encrypt the AWS credentials in .travis.yml because Travis generates a different RSA keypair for each repo, but I'm not sure. Can @zapier/devops take a look? They are currently copied from the original .travis.yml in zapier-platform-core.

[xavdid]

awesome, thanks for grabbing this! Had a couple of questions, most notably around split version support (which I'd really love to do), but nothing blocking.

[xavdid]

as far as I can tell, the presence of yarn.lock means that yarn will already be available (docs)

[eliangcs]

The one that Travis preinstalls is old and doesn't support yarn workspace command. npm install -g yarn is to upgrade the yarn version.

[xavdid]

Since i'm scared to actually run and test this command, can you talk a little about what actually happens when this is run?

My main concern is if we'll be able to easily version packages (mostly) individually. I think these will be our most common release patterns:

1. core alone: 9.0.1 -> 9.0.2 with no change in the schema dep
2. maj/min/patch release of schema, which causes the same in core (while depending on the new version). Eg, schema goes 9.0.1 -> 9.0.2, core goes from 9.0.2 -> 9.0.3 w/ a bugfix and updated schema dependency
3. major version of cli (8 -> 9), no change in cli / core

Are are all of those supported and straightfoward with this command?

[eliangcs]

lerna version is like going through each individual package and run yarn version command. For each package, it'll prompt us for the version to bump. Here's an example I've been using to test:

By default lerna version, only bumps the packages that have changed since the last tagged released. --force-publish is there to make sure to bump all three packages (cli, schema, core) every time we bump.

Separate versioning is also something I love to see happening, but I narrowed down the scope of this PR, so it only deals with the current situation, which is to version altogether. On the operating level, I think it should be easy to do separate versioning. We probably only need to remove that --force-publish part from the yarn bump command. The hard part is the application-level dependencies, how we find and remove them in each package.

[xavdid]

great attention to detail in these yarn usecases

[xavdid]

is there a reason we need to specify the registry here?

Also (though I imagine yarn publish uses npm publish under the hood), why not use yarn?

[eliangcs]

Great questions!

It's there because I tested the script with a self-hosted registry (Verdaccio to be specific). Probably a good idea to leave it there to make future testing easy.

I tried to use yarn publish but couldn't get it to work. There isn't an easy way to test yarn publish with a self-hosted registry. More importantly, unlike we can use an auth token with npm publish, yarn publish always asks for a password when publishing, which makes it impossible to work on CI.

[eliangcs]

@xavdid As a side note, I know we talked about dropping Lerna in favor of yarn workspace. But after looking into this, we probably should keep Lerna for its publish-related commands, which give us a nicer CLI.