Build duration is always 0 in Publishers

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Build duration is always 0 in Publishers

Pascal Bleser-4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

When Publisher.perform() is invoked on Publishers, Build.getDuration()
always returns 0.

This comes from the "end" timestamp being recorded *after* all
Publishers have been invoked in Run.run():
- ---8<--------------------------------------
onStartBuilding();
long start = System.currentTimeMillis();
//...
listener = new StreamBuildListener(new CloseProofOutputStream(log));
listener.started();
setResult(job.run(listener));
job.post(listener); // <= this is where Publishers are notified
// ...
long end = System.currentTimeMillis();
duration = end-start;
- ---8<--------------------------------------

The "problem" with this approach is that the build duration is not
available in Publishers (I wanted to display it in Jabber notifications).
The Result has already been set in the Build object though... wouldn't
it make sense to set duration _before_ job.post() is called ?

(just asking whether it would make sense or not, I'll open a bug if so ;))

Actually, I wonder whether registering Jabber, IRC or mail notifications
wouldn't make more sense as a BuildListener instead of a Publisher
(which is currently a Builder). Unfortunately, one cannot register
BuildListeners.

cheers
- --
  -o) Pascal Bleser     http://linux01.gwdg.de/~pbleser/
  /\\ <[hidden email]>       <[hidden email]>
 _\_v The more things change, the more they stay insane.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGLZQSr3NMWliFcXcRAqadAJ918l8vvGtX/U90QfaF31l7KBhGjACfT1Ld
aCmGiTR4zb95asUU+OUB+uA=
=exbw
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Build duration is always 0 in Publishers

Kohsuke Kawaguchi
Administrator
Pascal Bleser wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> When Publisher.perform() is invoked on Publishers, Build.getDuration()
> always returns 0.
>
> This comes from the "end" timestamp being recorded *after* all
> Publishers have been invoked in Run.run():
> - ---8<--------------------------------------
> onStartBuilding();
> long start = System.currentTimeMillis();
> //...
> listener = new StreamBuildListener(new CloseProofOutputStream(log));
> listener.started();
> setResult(job.run(listener));
> job.post(listener); // <= this is where Publishers are notified
> // ...
> long end = System.currentTimeMillis();
> duration = end-start;
> - ---8<--------------------------------------
>
> The "problem" with this approach is that the build duration is not
> available in Publishers (I wanted to display it in Jabber notifications).
> The Result has already been set in the Build object though... wouldn't
> it make sense to set duration _before_ job.post() is called ?
Some of the publishers, like test result recorder, could take a long
time, and I think that should be counted inside the build.

I was thinking about introducing another category "Notifier" for things
like mail and IM notifications. They implement the same signature as the
Publisher, but they will be invoked after the build is completed, and
their failures won't affect the build outcome. Something like that.

> (just asking whether it would make sense or not, I'll open a bug if so ;))
>
> Actually, I wonder whether registering Jabber, IRC or mail notifications
> wouldn't make more sense as a BuildListener instead of a Publisher
> (which is currently a Builder). Unfortunately, one cannot register
> BuildListeners.

One of the things I was hoping to improve some day was to allow
individuals to configure their own notifications, in addition to the
project-level configuration. For example, I should be able to say "if I
commit a change in any projects and that breaks the build, tell me via IRC".

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Build duration is always 0 in Publishers

Pascal Bleser-4
Kohsuke Kawaguchi wrote:

> Pascal Bleser wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> When Publisher.perform() is invoked on Publishers, Build.getDuration()
>> always returns 0.
>>
>> This comes from the "end" timestamp being recorded *after* all
>> Publishers have been invoked in Run.run():
>> - ---8<--------------------------------------
>> onStartBuilding();
>> long start = System.currentTimeMillis();
>> //...
>> listener = new StreamBuildListener(new CloseProofOutputStream(log));
>> listener.started();
>> setResult(job.run(listener));
>> job.post(listener); // <= this is where Publishers are notified
>> // ...
>> long end = System.currentTimeMillis();
>> duration = end-start;
>> - ---8<--------------------------------------
>>
>> The "problem" with this approach is that the build duration is not
>> available in Publishers (I wanted to display it in Jabber notifications).
>> The Result has already been set in the Build object though... wouldn't
>> it make sense to set duration _before_ job.post() is called ?
>
> Some of the publishers, like test result recorder, could take a long
> time, and I think that should be counted inside the build.

OK. It could be "cumulated" (so to say) or rather, overwritten before
each Publisher invocation:
- ---8<--------------------------------------
long start = System.currentTimeMillis();
//...
listener.started();
setResult(job.run(listener));
// HERE: set intermediate duration for Publishers
duration = System.currentTimeMillis()-start;
job.post(listener); // <= this is where Publishers are notified
// ...
long end = System.currentTimeMillis();
duration = end-start;
----8<--------------------------------------
...which makes it sort of "duration up to this point" (but still
somewhat of a hack, what you're proposing below is indeed a much
better solution)

> I was thinking about introducing another category "Notifier" for things
> like mail and IM notifications. They implement the same signature as the
> Publisher, but they will be invoked after the build is completed, and
> their failures won't affect the build outcome. Something like that.

Yes, would definitely make sense.
Them being Builders with the ability of breaking a build is... well...
wrong ;)
Shouldn't be too hard to implement either (but would require
refactoring of the current notification plugins).

>> (just asking whether it would make sense or not, I'll open a bug if so
>> ;))
>>
>> Actually, I wonder whether registering Jabber, IRC or mail notifications
>> wouldn't make more sense as a BuildListener instead of a Publisher
>> (which is currently a Builder). Unfortunately, one cannot register
>> BuildListeners.

OK, it does make sense, but as "Notifier"s, not "BuildListener"s

> One of the things I was hoping to improve some day was to allow
> individuals to configure their own notifications, in addition to the
> project-level configuration. For example, I should be able to say "if I
> commit a change in any projects and that breaks the build, tell me via
> IRC".

Hmmm... I see...
Could be implemented though. The mail, IRC and jabber notification
plugins do compute a list of "suspects" (users to blame) from SCM
ChangeLogSet records, although each plugin does it with its own
implementation (I shamelessly copied it from the IRC plugin).

The ChangeLogSet.Entry items (obtained through Build.getChangeSet())
already provide User domain objects through getAuthor().

Using the following method invocation chain:
ChangeLogSet.Entry.getAuthor().getProperties().get(JabberUserProperty.DESCRIPTOR)
it's already possible to retrieve Jabber-specific user properties
(same is done in the IRC plugin, and I suppose that one is copied from
the SMTP notification support code ;)).

Currently, JabberUserProperty only consists of the Jabber ID, but
there could be an additional checkbox/boolean flag "notify me when I
break something".

Of course, like this, it has to be implemented again and again in each
notification plugin... Generalizing it needs some more thoughts and
code ;)

cheers
--
   -o) Pascal Bleser     http://linux01.gwdg.de/~pbleser/
   /\\ <[hidden email]>       <[hidden email]>
  _\_v http://www.fosdem.org          http://opensuse.org

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]