Skip to content

Alpine linux tests failing #2615

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
kripken opened this issue Jan 23, 2020 · 1 comment · Fixed by #2621
Closed

Alpine linux tests failing #2615

kripken opened this issue Jan 23, 2020 · 1 comment · Fixed by #2621

Comments

@kripken
Copy link
Member

kripken commented Jan 23, 2020

For example

https://travis-ci.org/WebAssembly/binaryen/jobs/640703153?utm_medium=notification&utm_source=github_status

That started to happen, unrelated to code we landed. To verify I re-ran a job that succeeded and it failed.

The change might be something to do with the node version, as it gives a node error it didn't before.

This will prevent builds from being made, but otherwise I don't think we are losing any significant test coverage, aside perhaps from that our test runner may be incompatible with the node alpine just switched to.

@kripken
Copy link
Member Author

kripken commented Jan 24, 2020

This appears to be because we break on node 13.7.0.

kripken added a commit that referenced this issue Jan 24, 2020
…Module test suite integration. It's not clear to me if those are bugs or not. One change is we now get file://X paths instead of X in node-esm-loader.js, but working around that isn't enough, as even once the path is correct, it doesn't even try to load the env.js file, it just says it doesn't have the requested export, so the behavior has changed quite a bit it seems. fixes #2615
kripken added a commit that referenced this issue Jan 24, 2020
Using 13 led to a problem when they updated to 13.7.0, which
breaks our ES module test suite integration. It's not clear to me
if those are bugs or not. One change is we now get file://X paths
instead of X in node-esm-loader.js, but working around that isn't
enough, as even once the path is correct, it doesn't even try to
load the env.js file, it just says it doesn't have the requested export,
so the behavior has changed quite a bit it seems, perhaps
intentionally. Rather than spend more time, it seems safer to just
use the LTS release there. (But if this is intended and it reaches
LTS, we'll need to investigate more.)

fixes #2615
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant