search

browserify / node-util

node.js util module as a module
MIT License
247 stars 88 forks source link

Travis-ci: added support for ppc64le & Removed unsupported versions for ppc64le #53

Open dthadi3 opened 3 years ago

dthadi3 commented 3 years ago

Hi,

I had added ppc64le(Linux on Power) architecture & Removed unsupported versions for ppc64le support on Travis-CI in the PR and looks like its been successfully added.

Reason behind running tests on ppc64le: This package is included in the ppc64le versions of RHEL and Ubuntu - this allows the top of tree to be tested continuously as it is for Intel, making it easier to catch any possible regressions on ppc64le before the distros begin their clones and builds. This reduces the work in integrating this package into future versions of RHEL/Ubuntu.

Regards, Devendra

ljharb commented 3 years ago

Nothing about this package (or any pure-JS package that doesn't touch the filesystem) can vary based on architecture, so testing in other architectures is not valuable.

dthadi3 commented 3 years ago

Sorry for the late reply @ljharb I can see like package.json file lists the dependencies and that the build or testing can fail due to any of those as well and unless we actually run the builds we can probably never be 100% sure that it won't.

In General, we have seen that a lot of times node.js packages fail because of missing dependencies or dependencies on native code and such, in my automation that builds and validates a lot of these, we have found that to be the case for around ~20% of the packages. Ensuring that they build and all the unit tests pass on the target architecture and doing that via a CI on an on-going basis will ensure that we have complete coverage.

goto-bus-stop commented 3 years ago

we have seen that a lot of times node.js packages fail because of (..) dependencies on native code and such,

That makes a bit more sense. But this package targets browser environments primarily, and actually runs tests in various browsers too. Browsers don't support any native modules so we are already prevented from accidentally introducing such a dependency.

dthadi3 commented 3 years ago

@goto-bus-stop We appreciate for the additional information.

ljharb commented 3 years ago

Either way, running tests in other architectures is valuable for those native deps - if there's N native deps out there, why would it make sense to add stuff to CI for the N * M consumers of them, rather than just the N deps themselves?