Build trigger fails waiting for logs about jenkins-plugin HOT 14 CLOSED

@gabemontero ptal, this build took a long time to start, possibly because it was pulling the image. It appears in the meantime something timed out in the plugin and it decided the build was failed (with a null status). I think it may have timed out waiting for the logs to start, because the build step is configured to stream the logs back.

from jenkins-plugin.

Can we re-run this with verbose logging turned on (see the readme for
instructions)?

There are configurable timeout settings (also explained in the readme). We
could explore changing the default if the new pipeline stuff needs more
elbow room.

On Thursday, July 7, 2016, Ben Parees [email protected] wrote:

Assigned #47 #47 to
@gabemontero https://github.com/gabemontero.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#47 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ADbadP9W5BKYknI1u2KDsySg68Nxy2hwks5qTQz-gaJpZM4JHIZd
.

from jenkins-plugin.

it's probably going to be hard to recreate since it only happened when the image was being pulled (@rhamilto you could try docker rmi'ing the image locally so it has to be re-pulled next time).

at a minimum it seems like if we hit a timeout we need a better status report.

what is the default timeout?

from jenkins-plugin.

(I don't think the pipeline stuff is causing the timeout to need to be longer, since this was still just a straightforward "trigger a build and wait for it" build step)

from jenkins-plugin.

@bparees, i docker rmi-ed the image (and dependent images) and was able to reproduce the build failure on the initial build. The subsequent second build was successful (as it was earlier).

from jenkins-plugin.

@bparees - the default build timeout is 5 minutes.

Pending an update to that amount, I can certainly work on having the error message indicate that we quit waiting on the build to complete. I'll start on that in a bit.

from jenkins-plugin.

@gabemontero that's just a timeout waiting for the build to start, not a timeout waiting for the build to complete, right?

from jenkins-plugin.

@bparees no, it currently is the timeout to complete.

from jenkins-plugin.

@gabemontero I think we should raise that default to at least 15 mins then. (Along w/ making the error clear about why we gave up).

from jenkins-plugin.

@bparees will do ... I may have found a scenario where we quit waiting too soon. Addressing that will be part of the change.

from jenkins-plugin.

My proposal on the new message:

Exiting "Trigger OpenShift Build" unsuccessfully; build "ruby-sample-build-1" : did not complete successfully within the configured timeout; last reported status: [NotStarted].

from jenkins-plugin.

can we print the timeout value in the message?

otherwise lgtm

from jenkins-plugin.

Sure i'll add that

On Monday, July 11, 2016, Ben Parees [email protected] wrote:

can we print the timeout value in the message?

otherwise lgtm

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#47 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ADbadKZ-6C4mWNvUXcMjyksaaGEBd2Klks5qUqfRgaJpZM4JHIZd
.

from jenkins-plugin.

Fixes introduced with 9e4c19f

A pre-release version of the plugin with the fix is located here

V1.0.21 will be the released version with this fix.

from jenkins-plugin.