Added power support for the travis.yml file with ppc64le package: array-flatten

[sreekanth370]

Added power support for the travis.yml file with ppc64le. This is part of the Ubuntu distribution for ppc64le.
This helps us simplify testing later when distributions are re-building and re-releasing

[coveralls]

Coverage remained the same at 100.0% when pulling 911b12b on sreekanth370:master into 0a3aaed on blakeembrey:master.

[coveralls]

Coverage remained the same at 100.0% when pulling 911b12b on sreekanth370:master into 0a3aaed on blakeembrey:master.

[blakeembrey]

Can you help me understand why this is helpful and who for? I would have assumed this sort of difference is mostly needed in the engine (V8 or node.js) and not in individual libraries?

[sreekanth370]

Thanks for your response and tag for more info @gerrith3

[sreekanth370]

Hey, This is Power architecture - primarily the bigger enterprise class systems from IBM for banking/insurance/retail/etc.etc but this ensures that your code and all dependencies are tested on the Power architecture. Debian/Ubuntu, and Fedora/RHEL/CentOS have ppc64le (Power) distributions and this code goes into those distributions. This ensures that top of tree is always validated on ppc64le using (free) Power servers at Travis CI.

[blakeembrey]

Happy to merge 😄 Not sure I still understand though.

[gerrith3]

@blakeembrey So you are right that the compilers/interpreters clearly need work, but it is also possible to create architecture specific code, or find out that some of your dependencies are not architecture independent. This helps test your application against the versions of node, java, etc. on Power, including ensuring that all dependencies are also arch independent. If anything becomes arch dependent and broken on ppc64le you'll get a notification as soon as it happens so you can figure out how to address the issue. Hopefully that helps clarify a little bit?

[blakeembrey]

Makes sense. If I'm understanding, this is just so I don't break anything on ppc64le? In theory, if I never used architecture specific code, it would be safe.

[gerrith3]

Yes, and yes. ;) The problem is that most people aren't always able to recognize architecture specific code when they see it. Sure, an asm file is a dead give away, but having a .json file with dependencies, where some are fetched in the build process may pull in an Intel binary, which will flame out on a ppc64le box. Or an npm might fetch an npm as part of its run time with http/curl/whatever, not realizing that there either isn't an arch specific npm/binary or that they locked in on the intel version. This type of testing helps catch those cases up front by running directly on a ppc64le distribution just as an end user would see it. And it keeps you from having to have a bunch of 30,000 watt servers in your basement to test on. ;)