The simular situation polling schedule "* * * * *" works fine, but something like "0 9 * * *" with minutes and/or hours skips all checks:

Polling started on Apr 28, 2015 5:50:58 PM
Polling for the job Test_BuildResultTrigger
Recording context. Check changes in next poll.

Polling complete. Took 0 ms.
No changes.

instead

Polling started on Apr 28, 2015 5:56:58 PM
Polling for the job Test_BuildResultTrigger
Checking changes for job Test_BuildResultTrigger_1.
There are no new builds for the job Test_BuildResultTrigger_1.
Checking changes for job Test_BuildResultTrigger_2.
There are no new builds for the job Test_BuildResultTrigger_2.
Checking changes for job Test_BuildResultTrigger_3.
There are no new builds for the job Test_BuildResultTrigger_3.

Polling complete. Took 1 ms.
No changes.

Same with H 17 * * 5, the upstream job (makes the upstream/downstream automatically when i try to monitor a job) has its state as SUCCESS however after poll it says "No changes" and just stays like that. It should trigger upon "SUCCESS" and my option to "Combine all job info" is disabled.

I am running into the same issue. "* * * * *" combined with SUCCESS works but changing the cron value to something that has minutes or hours caused the job to never get triggered.

Anyone come up with a work around to the BuildResultTrigger plugin or another method to schedule executed based on the success of another job?

Thanks.

I can confirm this. Job is configured to poll once in the evening another job and it doesn't work. The following time setting does not work "0 18 * * 5" while "*/5 7-18 * * 5" does work after some poll (The log has no meaningfull output on the first poll)

I had look into the source code an I think this is a problem of the x-trigger-lib: It seems that the "context" member variable is marked as "transient". That means on serialization of the Trigger it will be discarded. I dont know much about java and jenkins but maybe the Trigger objects will be saved to disk if not used frequently. I think they're also serialized when beeing executed on another machine. If that happens, the previous state of the polled jobs is lost and the Trigger starts from a new state. This theory would alos explain the empty BuildResultTrigger log (No polled jobs seen).

I can confirm the same behavior for Build Result Trigger plugin. After a reconfiguration of the downstream job, the trigger skips a valid trigger. After a day or two, it starts triggering as expected.

We configure BRT with H H(0-6) * * * scheme.

The upstream job built successful at 7PM, BRT ran at 5AM and reported:

Polling started on Nov 17, 2016 5:10:00 AM
Polling for the job App_BB_VT5_APO_Nightly_SmokeTest
Recording context. Check changes in next poll.
Polling complete. Took 0 ms.
No changes.

First, I have no knowledge of the internal workings of Jenkins. But I have some questions so I can try to debug the problem a little further. I think that the plugin fails to do a proper initialization of its working data after a job reconfiguration.

1. Where does each Jenkins plugin keep its working data?

1. When a job is reconfigured, is it possible that the BRT plugin initializes its "last polled timestamp" to one day later?

I am seeing the same behavior. Any updates on this issue?

I could debug the issues as below.

Scenario:
job-A is an upstream project of job-B. job-B uses build result plugin to monitor job-A and if a new build is found for job-A for the set cron value, job-B should get triggered.

Jenkins ver:  2.71, BuildResultTrigger Plug-in ver: 0.17

Findings:
After Saving the configuration of job-B(by clicking on Apply/Save button), build result plugin will not trigger job-B on a very first time when it finds a new build for job-A on set cron value. But, it works as expected from second time onwards.

Steps to reproduce:
1. For example, current time is 2:15 am

2. job-B BuildResultTrigger settings:
        Job to monitor: job-A
        Job Build result: SUCCESS
        Schedule: H/5 2-5 * * *
This means- every day between 2 to 5 am, it should check on interval of 5 minutes

3. Trigger job-A, it should complete within a minute with SUCCESS

4. At 2:35 am, check BuildResultTriggerLog for job-B
This is the first time when job-A’s new build should have been monitored by build result plugin and should trigger job-B
But it will not work and will show logs like this,

Polling started on Mmm dd, YYYY 2:35:00 AM
Polling for the job job-B
Recording context. Check changes in next poll.
Polling complete. Took 0 ms.
No changes

5. At 2:40 am, check BuildResultTriggerLog for job-B
As there was no new build triggered for job-A, it will show something like this,

Polling started on Mmm dd, YYYY 2:40:00 AM
Polling for the job job-B
Checking changes for job-A.
There are no new builds for the job job-A.

Polling complete. Took 0 ms.
No changes.

6. Trigger job-A second time, it should complete within a minute with SUCCESS. Make sure between step 2 and 6 you have not changed the project configurations for job-B

7. At 2:45 am, check BuildResultTriggerLog for job-B
This is the second time when job-A’s new build should have been monitored by build result plugin and should trigger job-B
This time it will work and will show something like this,

Polling started on Mmm dd, YYYY 2:45:00 AM
Polling for the job job-B
Checking changes for job job-A.
Checking expected job build results for the job job-A.
Checking SUCCESS
Last build result for the job job-A matches the expected result SUCCESS.
Job job-A is modified. Triggering a new build.

Polling complete. Took 0 ms.
Changes found. Scheduling a build.

8. Now onwards, build result plugin will work as expected until you update the project configuration for job-B