Use Release API for binary downloads

[nschonni]

While a tag shouldn't be altered once it's been made, the GitHub release API allows files to be attached to the release https://developer.github.com/v3/repos/releases/#upload-a-release-asset
This would mean that platform specific binaries could be built and attached after the code had been tagged. This would be a solution to the recent issue of frequent io.js releases in between official tagged releases. People could just check out the latest release tag and build for the new platform to be supported.

[am11]

At some point, we were gauging the options to either use gh-API or amazon S3 bucket with node-pre-gyp (#56), until this CentOS incompatible binary issue showed up.

BTW, shouldn't we use this API for uploading the binaries only? I mean the download URL will remain the same: raw.githubusercontent.com.., no?

[nschonni]

I think the new download URL would be something like https://github.com/sass/node-sass/releases/download/v3.0.0/darwin-x64-4.1.0.21.zip (https://developer.github.com/v3/repos/releases/#get-a-single-release-asset) for OSX io.js 1.4 given what you found in #710 (comment) plus the switch back to using the V8 version as the identifier.

[am11]

Nice one! So basically we can upload assets to node-sass repo, instead of having a separate node-sass-binaries repo.

I think something like this will do the trick: https://gist.github.com/am11/a4a708120f16934f5d81 (credit goes to this guy: http://stackoverflow.com/a/26680032/863980).

We can then place upload.js in scripts/ directory and call it like:

node scripts/build -f
# then
node scripts/upload --user am11 --auth myGitHubOAuthToken

myGitHubToken was build from public access token section: https://github.com/settings/applications#personal-access-tokens with public-repo check marked. (on personal device, we can probably store the token in env var and echo it on publishing the binary.

[am11]

Incidentally, will these upload assets appear in the repository?

[nschonni]

I think the binaries should still stay in the separate repo, and then we just copy them to the release when the release goes live.

[am11]

I agree. This way, we can take binaries contribution even after the node-sass build has released.

We can think about knitting #720, #389, #689 and this one to form a versatile build strategy, which will allow users to specify:

• which binary they want to fetch at install time (Changing binary #689; supply an custom argument to npm install node-sass).
• which commit they want to build the binary against: Expose config param to allow specific libsass commit for build #389 (perhaps we don't need to provision it in package.json, we can simply take libsass-commit-hash as argument like node scripts/node --libsass-hash <hash>). This can happen on the already existing installation as well as the install time (npm install node-sass --libsass-hash <hash>).
• the location of binary by setting the environment var SASS_BINARY_PATH=/my/favorite/path/blah.node (not exactly but inspired by Download sass binary from environment variable url #720).
• the URL to download binary from by setting the environment var SASS_BINARY_URL=http://my-favorite-cdn-url/downloads (Download sass binary from environment variable url #720).

Then for the release, we will:

• bootstrap by tagging the node-sass-binary with same tag as node-sass (like we do today). This is just for our accounting and has nothing to do with npm install step.
• Make a draft release on node-sass, throw in the collected binaries from node-sass-binaries repo:

• Save release and publish npm.

On npm install node-sass, it will download from https://github.com/sass/node-sass/releases/download/---/--.node/

Later if we realize that some new binary needs to be uploaded for this (published) release, we can use the GH API upload script (node scripts/upload --argument-able) to add it to the release.
If we realize that the existing binary is broken and need replacing, we cannot delete it but we can rectify it by adding another binary with same_name + "v1" and ask the user to either:

• Download the binary and set the SASS_BINARY_PATH=/my/downloads/blah.node or replace the existing vendor/blah/blah.node.
• Reinstall node-sass like:
  • SASS_BINARY_URL=https://download.github.com/sass/node-sass/blah/blah-v1.node && npm install node-sass
  • or npm install node-sass --sass-binary linux-x64-<my-v8-version>.

If they need to download binaries for multiple OSes (for distilled deployment use-cases: as #689), they can npm install node-sass --save-binaries linux-x64-<my-v8-verson> linux-x86-<my-v8-verson> darwin-x64-<my-v8-verson> <-- this will essentially skip the binary testing on install.

Even the post-release-binaries will also be pushed to node-sass-binaries repo first and then a tagged release will be made for instance: v3.0.0-post-v1, v3.0.0-post-v2 etc. This way we will keep record of all binaries ever happen to node-sass from Sass Org and by whom (but we cannot assert this policy in code I suppose, since this is matter of workflow which can be violated by just not following the workflow)..

Thoughts?

[xzyfer]

👍 x 💯