Better messages in Jenkins job logs about jenkins-plugin HOT 17 CLOSED

@gabemontero @bparees what do you think?

from jenkins-plugin.

@mfojtik +1

@gabemontero and I already did some light reviewing of these messages, but there is definitely more aggressive editing that can be done.

from jenkins-plugin.

I'll add the specific message edits. @bparees had another one he noted via a gist (though I'm not 100% sure what is wrong with what he posted, need to look again).

And I think the idea of replacing the java class name with some sort of reference to what the build step is a good one. I'm thinking the build step display name when they select it, unless you all have another suggestion.

Apologies, but I'm not in agreement about losing the EXIT prints. They have already served as useful debug, without the full verbose option, for customer questions, and have expedited either debug or correction to user error on several occasions already.

There is an option to dump the build output. It currently is not real time because of some java level concerns. The openshift-restclient-java package from the eclipse folks have real time version, but it employs the oc binary located in the jenkins image under the covers. If you all recall, we made a conscious decision to not depend on the oc binary (I'm assuming the reasons are self explanatory).

Links to the console ... is the login URL another env var that @mfojtik has recently added ? ... even if it is, I'm on the fence

from jenkins-plugin.

Apologies, but I'm not in agreement about losing the EXIT prints

I'm sympathetic to that and since you're the guy who's going to bear most of the burden of debugging these issues, it should probably be left up to you. That said, we can probably at least make them more human readable and less debug-looking.

eg "Finished xyz with result abc"

Links to the console ... is the login URL another env var that @mfojtik has recently added ? ... even if it is, I'm on the fence

it's not, which is definitely a significant challenge. I don't know that we have a good way to know what the console url is. I would definitely leave that as a separate wishlist item from the other cleanup.

from jenkins-plugin.

OK cool ... got to spend some online cycles, but hope to circle back to this before EOB today.

from jenkins-plugin.

@bparees @mfojtik - I have a preliminary sample. Before I took the time to apply a similar pattern to all the steps, I'd like to solicit feedback. Note, the "Starting ...Started..." is one line (in case this comment does not render it that way):

Starting the "Perform builds in OpenShift" build step with build config frontend from the project test. Started build frontend-3 and will not wait for any subsequent deployment to succeed.

Exiting "Perform builds in OpenShift" succesfully; build frontend-3 has completed.

from jenkins-plugin.

1. We should quote all the parameters, eg
   Starting the "Perform builds in OpenShift" build step with build config "frontend" from the project "test". Started build "frontend-3" and will not wait for any subsequent deployment to succeed.

2. Regarding the exact message... in the case where we're not doing something (not waiting for deployment, not waiting for exact replica count, etc) i'd just not mention it, eg:

Started build foo and will wait for build completion
Started build foo and will wait for build completion followed by a new deployment

3. "Perform builds in OpenShift" sounds pretty wordy as a step name, and "build step" is probably redundant since everything jenkins does is a build step. (just "step" should be sufficient), so how about, pulling it all together:
   Starting the "Trigger OpenShift Build" step with build config "foo" from project "test". Started build "foo-1" and waiting for build completion..."

4. though you said those two things are on the same line, I think they might be better as two lines:
   Starting the "Trigger OpenShift Build" step with build config "foo" from project "test".
Started build "foo-1" and waiting for build completion..."

(or if the checkbox to watch for a deployment is set):
Started build "foo-1" and waiting for build completion followed by a new deployment..."

(note also the addition of the "..." to indicate an in progress step)

5. For the exit message:
   Exiting "Trigger OpenShift Build" successfully; build "foo-1" has completed with status: [complete|failed|error]

(I assume "successfully" would also say "unsuccessfully" if the build had failed/errored?)

Also what exit message will you give if the build completed successfully but we were waiting for a deployment to be triggered and it wasn't?

from jenkins-plugin.

OK, I'll apply 1) through 5). Answers to your questions embedded below.

On Wed, Feb 24, 2016 at 4:59 PM, Ben Parees [email protected]
wrote:

1. We should quote all the parameters, eg
   Starting the "Perform builds in OpenShift" build step with build config
   "frontend" from the project "test". Started build "frontend-3" and will not
   wait for any subsequent deployment to succeed.

2. Regarding the exact message... in the case where we're not doing
   something (not waiting for deployment, not waiting for exact replica count,
   etc) i'd just not mention it, eg:

Started build foo and will wait for build completion
Started build foo and will wait for build completion followed by a new
deployment

3. "Perform builds in OpenShift" sounds pretty wordy as a step name, and
   "build step" is probably redundant since everything jenkins does is a build
   step. (just "step" should be sufficient), so how about, pulling it all
   together:
   Starting the "Trigger OpenShift Build" step with build config "foo" from
   project "test". Started build "foo-1" and waiting for build completion..."

4. though you said those two things are on the same line, I think they
   might be better as two lines:
   Starting the "Trigger OpenShift Build" step with build config "foo" from
   project "test".
   Started build "foo-1" and waiting for build completion..."

(or if the checkbox to watch for a deployment is set):
Started build "foo-1" and waiting for build completion followed by a new
deployment..."

(note also the addition of the "..." to indicate an in progress step)

5. For the exit message:
   Exiting "Trigger OpenShift Build" successfully; build "foo-1" has
   completed with status: [complete|failed|error]

(I assume "successfully" would also say "unsuccessfully" if the build had
failed/errored?)

Yes it would. Right now (not accounting for your above edits around step
name, etc. - I will similarly apply those comments), there are these set of
messages:
a) Exiting "%s" unsuccesfully; a build could not be started.
b) Exiting "%s" unsuccesfully; the build pod for build %s was not found
in time.
c) Exiting "%s" unsuccesfully; the state of the build %s is %s.
d) Exiting "%s" unsuccesfully for build %s; not all deployments with
ImageChange triggers based on this build's output triggered off of the new
image.
e) Exiting "%s" unsuccesfully; the build config % could not be read.
f) Exiting "%s" unsuccesfully; a client connection to %s could not be
obtained.

for a) the REST call to start the build came back in error
for b) we failed to access the build pod via REST ... we do this to dump
the build logs
for c) either it explicitly failed, or by the end of our wait timeout, the
state of the build is something other than COMPLETE
for d) we are in verify deployment mode, and some deployments did not fire
in time
for e) we could not access the build config via the REST api
for f) we could not get a client connection

Also what exit message will you give if the build completed successfully
but we were waiting for a deployment to be triggered and it wasn't?

see above

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

from jenkins-plugin.

two s's in successfully/unsuccessfully, but otherwise cool, that makes sense.

from jenkins-plugin.

OK ... some posting of updated samples for the build step. Pending more fine tuning, will move on to next step:

Starting the "Trigger OpenShift Build" step with build config "frontend" from the project "test".
Started build "frontend-2" and waiting for build completion ...

Exiting "Trigger OpenShift Build" successfully; build "frontend-2" has completed with status: [Complete].

Starting the "Trigger OpenShift Build" step with build config "frontend" from the project "test".
Started build "frontend-3" and waiting for build completion followed by a new deployment...

Exiting "Trigger OpenShift Build" successfully; build "frontend-3" has completed with status: [Complete]. All deployments with ImageChange triggers based on this build's output triggered off of the new image.

from jenkins-plugin.

A couple of samples for the new scaler messages:

Starting the "Scale OpenShift Deployment" step with deployment config "frontend" from the project "test".
Scaling to "0" replicas and verifying the replica count is reached....

Exiting "Scale OpenShift Deployment" successfully, where the deployment "frontend-5" reached "0" replicas.

Starting the "Scale OpenShift Deployment" step with deployment config "frontend" from the project "test".
Scaling to "0" replicas...

Exiting "Scale OpenShift Deployment" successfully.

from jenkins-plugin.

they look good to me. probably wait until @mfojtik gives it a second set of eyes before committing to making changes though.

from jenkins-plugin.

Roger that (comment above ^^).

Some samples for the deploy verify:

Starting the "Verify OpenShift Deployment" step with deployment config "frontend" from the project "test".
Verifying deployment state...

Exiting "Verify OpenShift Deployment" successfully.

Starting the "Verify OpenShift Deployment" step with deployment config "frontend" from the project "test".
Verifying deployment state and verifying the current deployment is at "1" replica(s)....

Exiting "Verify OpenShift Deployment" successfully, where the deployment "frontend-5" is at "1" replicas.

from jenkins-plugin.

verify deployment step messages look good to me.

from jenkins-plugin.

@bparees @gabemontero much better now :-) looks good to me as well.

from jenkins-plugin.

@bparees @mfojtik cool deal ... do you all want me to continue to post the updates for each build step as I compose them, or have we established enough of a pattern where it is essentially plug-n-play.

Here is the list of renamed step names as noted in the readme, and will show up as from the pull down:

1. "Trigger OpenShift Build"
2. "Scale OpenShift Deployment"
3. "Trigger OpenShift Deployment"
4. "Verify OpenShift Service"
5. "Tag OpenShift Image"
6. "Verify OpenShift Deployment"
7. "Verify OpenShift Build"
8. "Create OpenShift Resource(s)"

The post build actions:

1. "Cancel OpenShift Builds"
2. "Cancel OpenShift Deployments"

Image stream poller:
"Monitor OpenShift ImageStreams"

from jenkins-plugin.

yeah i think we can probably hash out any further nuances in your PR

from jenkins-plugin.