Run OSX builds in Travis CI

[xzyfer]

I've been following travis-ci/travis-ci#2311 and it seems like getting a node project to build on OSX should be doable with some persistence.

I'm mostly just PR'ing this so Travis will build it. Feel free to ignore for the time being. This could be a complete failure.

It took a bit of doing but this works! I'm only building OSX for 0.12 and 4 for now to keep builds quicky-ish.

[xzyfer]

Thoughts @am11 @saper ?

[saper]

There is nothing to think about :) only to act! I think we should work in this direction - and maybe whenever a tag is pushed we should be prepared to do a full run on OS X to create & deploy binaries.

One question - why do you need to install python from homebrew? something is not working?

[am11]

This is brilliant! 👍
IMO, let OSX also run the entire matrix. The docker infrastructure is already delivering significant speed.

[xzyfer]

whenever a tag is pushed we should be prepared to do a full run on OS X to create & deploy binaries

That's the plan. Ideally I want to wire this and your AppVeyor work into node-pre-gyp

let OSX also run the entire matrix

This as frustratingly slow. I double the number of simultaneous builds in Travis but didn't help too much.
TBH iojs 1,2 are on their way out IMHO once people the update Node 4.

[xzyfer]

why do you need to install python from homebrew

node-gyp wants python2 in the path. This isn't present by default but brew puts it the right place. The docs suggest python2 is install on the machines so maybe there's an env I can use to switch where node-gyp is looking.

[xzyfer]

node-gyp wants python2 in the path
The docs suggest python2 is install on the machines so maybe there's an env I can use to switch where node-gyp is looking.

Turns out this is possible with

npm config set python `which python`

No more brew

[xzyfer]

This as frustratingly slow

Not running brew along with double the concurrent builds has made running the whole matrix feasible fast. 👍

[xzyfer]

😍😍😍😍

[am11]

double the concurrent builds has made running the whole matrix feasible fast.

Wow! This is already in excellent shape. Lets merge it then! Further improvements can continue to follow over time. 😄

[saper]

I think that eventual migration to node-pre-gyp (as a replacement for our scripts/* infrastructure) is a different (larger?) project.

From the context I presume you would like to use node-pre-gyp publish feature? Somehow I feel we can be further ahead with GitHub releases and the built-in deployment feature of CIs.

I'd love to use node-pre-gyp to kill our own lifecycle scripts, but I don't want to add another custom script and another resource (S3) to have deployment of the binaries done.

One thing to decide before we go ahead with either solution is that should agree first how to trigger the release build - is having a separate release branch an option? New release would be commited to master (with the release notes as the commit comment) and then pushed to the release branch with a tag. The AppVeyor script from #1135 is ready to do it right away.

The only reason we might need a separate branch is http://bit.ly/twoBuilds issue - with a separate branch I can configure package building on commit push instead of tag push.

[xzyfer]

I think that eventual migration to node-pre-gyp [..] is a different (larger?) project.

I agree. Just something I want us to keep in mind.

From the context I presume you would like to use node-pre-gyp publish feature? Somehow I feel we can be further ahead with GitHub releases and the built-in deployment feature of CIs.

IIRC node-pre-gyp backs on the built-in features of each CI platform. It's largely just a single point of config which is used to delegate to each CI platforms implementation of "release/publish artefacts to X"

is having a separate release branch an option?

I have previous suggested we (libsass) adopt a stable branch to allow backporting features to old releases - sass/libsass#796. This is not dissimilar from the release branch.

Personally this is something I would prefer to avoid.

The only reason we might need a separate branch is http://bit.ly/twoBuilds issue

Does this not help? https://help.appveyor.com/discussions/questions/261-only-deploy-when-theres-a-new-tag#comment_37132177

[saper]

On Mon, 14 Sep 2015, Michael Mifsud wrote:

From the context I presume you would like to use node-pre-gyp publish feature? Somehow I feel we can be further ahead with GitHub
releases and the built-in deployment feature of CIs.

IIRC node-pre-gyp backs on the built-in features of each CI
platform. It's largely just a single point of config which is used
to delegate to each CI platforms implementation of "release/publish
artefacts to X"

node-pre-gyp does not seem to care which CI platform
is being used, it just takes two variables from the
build environment and uses them as the S3 keys,
and then uses AWS SDK to push to S3.
So, no magic there.

is having a separate release branch an option?

I have previous suggested we (libsass) adopt a stable branch to allow backporting features to old releases - sass/libsass#796. This is not dissimilar from the release branch.

Personally this is something I would prefer to avoid.

Me too. But for now(?) we could just make "release" to fully mirror
"master" - we push current master to release only to trigger
the build. This branch would be nothing special and can be deleted
after the build is triggered.

The only reason we might need a separate branch is http://bit.ly/twoBuilds issue

Does this not help? https://help.appveyor.com/discussions/questions/261-only-deploy-when-theres-a-new-tag#comment_37132177

Nope, see my comment below ... it triggers a while build on the release
branch (say, "master") commit and then does deployment only when there
is a tag. It is hard to push a tag and a commit at the same time
so that appveyor does not start two builds:

• commit-only -> builds 32- & 64-bit but does not deploy
• tag-only -> builds 32-bit only, does not publish artifacts and does not deploy;
  deployment rule is never reached.

I know it sounds complicated, I hope Fedor somehow responds to that...