Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-291

a record needed why a build has started (what triggered it)

    • Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • None
    • Platform: PC, OS: Linux

      It would be good to know what a build triggered. When a user triggered it via
      the web-site I would like to know who it was (that requires authentication).
      Other build reasons: a succeeded build of another project, a wget request by a
      script, a cron trigger.

        1. patch.291.feb8
          20 kB
        2. patch.291.feb5
          19 kB
        3. patch.issue291.4feb
          17 kB
        4. patch.291
          15 kB

          [JENKINS-291] a record needed why a build has started (what triggered it)

          gradopado created issue -
          Kohsuke Kawaguchi made changes -
          Link New: This issue is blocking JENKINS-324 [ JENKINS-324 ]

          abonko added a comment -

          Yes, being able to identify what triggered a build would be very useful.

          abonko added a comment - Yes, being able to identify what triggered a build would be very useful.

          bwestrich added a comment -

          +1
          I really miss in Hudson (CruiseControl has this feature, whew, how about flame
          bait!!!) the ability to see why a build happened. Was it because of an SCM poll,
          an upstream project build (if so, which one), a timed build, or a manual build
          (if so, by who)?

          bwestrich added a comment - +1 I really miss in Hudson (CruiseControl has this feature, whew, how about flame bait!!!) the ability to see why a build happened. Was it because of an SCM poll, an upstream project build (if so, which one), a timed build, or a manual build (if so, by who)?

              • Issue 1124 has been marked as a duplicate of this issue. ***

          Kohsuke Kawaguchi added a comment - Issue 1124 has been marked as a duplicate of this issue. ***
          Kohsuke Kawaguchi made changes -
          Link New: This issue is duplicated by JENKINS-1124 [ JENKINS-1124 ]

          adding myself as CC

          jameslivingston added a comment - adding myself as CC

          redsolo added a comment -

          The trigger record should contain a short reason and an optional longer command
          output (or description). The command output is interesting if a job is triggered
          by a SCM, and the user is wondering why the SCM triggered it. (See discussion
          http://www.nabble.com/Hudson-executes-build-even-though-no-SCM-changes-were-recorded-td18736261.html)

          redsolo added a comment - The trigger record should contain a short reason and an optional longer command output (or description). The command output is interesting if a job is triggered by a SCM, and the user is wondering why the SCM triggered it. (See discussion http://www.nabble.com/Hudson-executes-build-even-though-no-SCM-changes-were-recorded-td18736261.html )

          mdonohue added a comment -

          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.

          mdonohue added a comment - 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.

          mdonohue added a comment -

          My second question is larger than I had realized. Browsing the code this
          evening, I'm seeing Task and Item objects as part of the queue manipulation
          code. On the model side, there are Job, Run, Project and Executor objects.
          This is more than I was considering, so I'd like to understand better the best
          place to store the reason for launching a job/project. I think the 'build
          reason' needs to end up on the Run object, but that object is not created until
          well after the project has been enqueued, so a series of storage places need to
          be identified.

          mdonohue added a comment - My second question is larger than I had realized. Browsing the code this evening, I'm seeing Task and Item objects as part of the queue manipulation code. On the model side, there are Job, Run, Project and Executor objects. This is more than I was considering, so I'd like to understand better the best place to store the reason for launching a job/project. I think the 'build reason' needs to end up on the Run object, but that object is not created until well after the project has been enqueued, so a series of storage places need to be identified.

            mdonohue mdonohue
            gradopado gradopado
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: