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
Extend Travis build time-out #11319
Extend Travis build time-out #11319
Conversation
From reading this, it seems like |
Yes, 20 minutes is the default. Let's see what happens because right now it cuts off at 10. |
... you mean at 30 It looks promising! |
almost there. updating to 40. |
trying again with timeout set to (!!!) 60. |
In spite of the commit message saying "Update timeout to 60", the timeout still seems to be 40! Although this time it passed. |
Might try this again just for fun... |
forgot to add the file to the commit. timeout now set at 60 and re-pushed. |
I was going to try making the timeout be a shell variable, and then we could leave it at the default for all but the one problematic platform, but I don't think it's necessary. If every build takes its maximum of an hour, we'll notice the backlog I think. So taking this out of WIP. Should be backported, too. |
Well that didn't quite work out as planned - 2 travis timeouts. (It still seemed to timeout after 50 minutes?) |
I'm not sure that just increasing timeout is a decent way to deal with this problem... |
Hmmm, the timeouts we see seems to be largely due to This may mean that some dependencies get a later timestamp than expected, causing another recompile. This is actually an old problem that isn't unique to us. I recall that some GNU documentation recommend |
I encountered this behaviour locally too several times. At some time I suspected that it has to do with the conversion of some |
When you fiddle around with branches, it's mostly any changes in header file dependencies that may trigger an extra rebuild. |
Since we did just build, then perhaps using _tests as the target makes sense. Trying that now. |
And travis_retry to some apt-get commands.
I hope that it works out at all times and doesn't have us depend on luck... |
I don't see what could go wrong (famous last words), but it worked. So, ready for review. |
Considering the caches are probably PR specific, it's highly probably nothing goes wrong. I've seen things going wrong, i.e. needing a second recompile, but that's been when I've jumped wildly between branches, so.. |
I supect that things are different enough between 1.1.1 and master that 1.1.1 might need a separate PR |
1.1.1 PR in #11331 |
Since this PR seems to address the near-constant CI timeouts, it seems helpful to get this merged sooner rather than waiting? |
Yup. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@t8m, I propose "urgent". Do you agree? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree it's urgent.
I squashed the two commits and slightly edited the joined commit message, see d18dae018278ed4883b6b2f795e315e9d89c7cd9. @richsalz @levitte @t8m do I have your approval to push it like this?
|
Oh, sorry, I should have used your pull request title as subject line. Hang on for a second...
|
- Add travis_wait to the build command - And travis_retry to some apt-get commands. - Use `make _tests` instead of `make test` Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from openssl#11319)
Done, see fd32f91. |
fine with me. |
Ok, then I'll push it now. |
- Add travis_wait to the build command - And travis_retry to some apt-get commands. - Use `make _tests` instead of `make test` Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from #11319)
now you've jinxed it :) |
Are you saying I should have kept my mouth shut until Travis has completed? I hope, I didn't mess it up... |
Replaces #11313 which I could not re-open because I force-pushed before reopening. Who knew? :)