Skip to content
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

travis kills jobs with no I/O after 10 minutes #38

Open
dalehenrich opened this issue Feb 27, 2013 · 6 comments
Open

travis kills jobs with no I/O after 10 minutes #38

dalehenrich opened this issue Feb 27, 2013 · 6 comments

Comments

@dalehenrich
Copy link
Owner

3 of the jobs run for this test sequence were killed by travix with the following message:

111PROCESSING OPTIONS
112BUILDING IMAGE FILE
113Linux testing-bluebox-linux-3-8728-linux-1 2.6.32-042stab061.2 #1 SMP Fri Aug 24 09:07:21 MSK 2012 x86_64 x86_64 x86_64 GNU/Linux
114RUNNING TESTS...
115
116
117No output has been received in the last 10 minutes, this potentially indicates a stalled build or something wrong with the build itself.
118
119The build has been terminated

The other runs came close to hitting 10 minutes and were allowed to continue ... the way we run the vm nothing gets written to standard out until the job finishes so any test/build sequence that runs for ten minutes in the vm will be killed by travis ...

I think I need to add some progress indicators to prevent travis from killing the job prematurely ... run the risk of infinite hangs, but as it stands now it looks like half of my jobs get killed for no legitimate reason ... I HATE TIMEOUTS:)

@dalehenrich
Copy link
Owner Author

first stab

@dalehenrich
Copy link
Owner Author

Current travis-ci time limit is 50 minutes ... so we can bump the artificial timeout up if necessary..

@dalehenrich dalehenrich reopened this May 6, 2014
@timfel
Copy link

timfel commented Aug 1, 2014

Would it be nicer if the Transcript got piped also to stdout? Then we don't need this hack and can actually see progress...

@fniephaus
Copy link
Collaborator

That'd be very convenient, but I can't tell how much work that would be.

@timfel
Copy link

timfel commented Aug 1, 2014

It's actually how we did it with our Swa fork of builderCI that we had two ys ago. Subclass TranscriptStream, open a file, and override writing methods to forward to the file and FileStream stdout. Then replace Smalltalk at: #Transcript with an instance of that subclass.

Just have to figure out where stdout is in Pharo 3.

@dalehenrich
Copy link
Owner Author

It would be nice to get all the Smalltalks "behaving" in batch mode:)

I've been using Pharo3.0 for scripting recently and when run headless,
using the command line support (CommandLineHandlers and friends) stdout
actually seems to work... I think that Transcript is mapped to stderr

On Fri, Aug 1, 2014 at 8:11 AM, Tim Felgentreff [email protected]
wrote:

It's actually how we did it with our Swa fork of builderCI that we had two
ys ago. Subclass TranscriptStream, open a file, and override writing
methods to forward to the file and FileStream stdout. Then replace Smalltalk
at: #Transcript with an instance of that subclass.

Just have to figure out where stdout is in Pharo 3.


Reply to this email directly or view it on GitHub
#38 (comment)
.

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

No branches or pull requests

3 participants