Timeout Issues on Travis

[skipjack]

Just to be clear this isn't necessarily an issue with this package. It's just that after a conversation with @Munter we decided this would be the most logical place for the discussion.

We’ve been having some issues when running hyperlink on Travis for the webpack.js.org repository. Essentially, our build and other tests run but when hyperlink (the lint:links npm script) runs, it takes longer than 10 minutes and travis terminates the build. This issue has been somewhat inconsistent, but in the last few days has gotten worse. The odd thing is that locally it runs much faster (~5 min).

One of our contributors (@pierreneter) dug into it a bit and came to the conclusion that it’s probably the Travis' network that's slowing things down. I guess my questions are just…

• Has anyone run into this before and is the Travis network theory correct?
• Does anyone have ideas for a workaround or solution to this?

I tried travis_wait by the way, which I guess might be one solution, but I think we’d have to rework our .travis.yaml file a bit to get that to work.

[skipjack]

Quoting @Munter...

Travis network could be a reason. It might be worth getting in contact with them to get them to weigh in on the issue. If they throttle network that might explain things. And to be honest, if I was running such a service I probably would throttle. This could just as easily be a DDOS machine. I don't think we use a lot of bandwidth after I switched to prefer HEAD requests, but limiting the amount of connections or slowing down the connection instantiation might very quickly accumulate to large delays.

[skipjack]

@Munter I'll look into reaching out to someone from Travis (let me know if you have any suggestions). I'll also create a branch/pr on the docs repo so we can test, and hopefully resolve, the issue.

[skipjack]

Created webpack/webpack.js.org#1582 so we can try to resolve this issue. It is hard to replicate at a times but hopefully we'll be able to so we can address it before adding hyperlink back in on master.

[Munter]

https://twitter.com/travisci/status/907555425536659456

[skipjack]

@Munter thanks, sent them a message. Will add an update once I hear back.

[skipjack]

@Munter they got back to me with the following questions:

Would it be possible to get a more verbose output of the external link checker? It would be good to get a sense of what is happening (How many threads, duration of requests, etc.)

Would it help if you could ssh into the VM and see if you manage to reproduce the issue?

I'm going to add you to the thread as well. It does seem like these things would help but may require npm linking hyperlink or something to debug thoroughly? I could also pass --verbose to hyperlink on that PR if you think that might help.

The only issue is that we pass the output from hyperlink to a check-links.js script that excludes certain failures. However, on that PR I could remove the part that pipes it to the custom script and allow it to run clean.

[skipjack]

Determined this isn't really an issue with hyperlink...

webpack/webpack.js.org#1582 (comment)

[Munter]

Looks like the missing default timeout of teepee might be at fault. Reopening.

[Munter]

@skipjack Could you maybe give the fix/defaultTimeout branch a go and see if hyperlink behaves better in your CI setup?

[skipjack]

Yes will do, thanks!

[skipjack]

@Munter not sure if you saw the comment on webpack/webpack.js.org#1582 but that branch didn't fix the issue unfortunately. It still hangs for over 10 min on certain links.

[Munter]

Fixed by properly unloading assets while traversing the graph. Will be out in v4.x