I'm taking a look at this. I think the best approach is to modify
BuildableItem, and change the method 'boolean scheduleBuild()' to take an
argument explaining why the build is being scheduled, then fix all callers to
include an explanation, and add a UI element to show the reason.
I have two questions though. One is how backward compatibility affects this. I
think I would have to leave the old no-argument method in place, and have it
give 'unknown' or 'legacy code' reason for launching the build. However, if
it's possible to remove the old method, I would prefer to do that.
The second question is what to store in the job itself. The boolean return
value indicates whether the job is already in the queue. This means we could
have several reasons for a job being built - the easy solution would be to
record only the first reason, but the more complete solution would be to queue
up all the reasons on the job, so they can all be browsed. I think I'll start
with the easy route, and see about adding the list later.
Yes, being able to identify what triggered a build would be very useful.