The ivy trigger plugin saves the resolved dependencies from each run in memory. This has the effect that when jenkins is restarted, the in-memory resolved dependency tree, stored as a <C extends XTriggerContext> instance in class AbstractTriggerByFullContext, is lost.

If a binary dependency changes in the repository after the last run of the trigger and before a jenkins restart, ivytrigger-plugin loses track of current state, and changes in dependencies can be missed. We have found this problem is worst for jobs which poll for changes infrequently. e.g. where we only want the job to build once per night, and hence only poll on that frequency.

We have modified a locally modified version of the ivytrigger plugin to write the IvyTriggerContext object to disk as a serialized java object in the job config directory on the master server. This happens each time the trigger runs. When the trigger runs, if the context is null, it is read into memory from the serialized object to reinitialise the in-memory state of the previously resolved dependency tree.

My modifications are based on a previous fork of version 0.32 which we used for local changes and is located at https://github.com/alexouzounis/ROE-ivytrigger-plugin.git

I no longer have write access to this repository and so imported its contents into my own repository at https://github.com/imacd/roe-ivytrigger-plugin.git I have made the modifications for persisting state to disk in that branch. The changes include the ability to switch the persisted state on and off on a job by job basis in the UI config panel.

Since the field AbstractTriggerByFullContext.context is private, I have employed copy-paste-modification of the class AbstractTriggerByFullContext as org.jenkinsci.plugins.ivytrigger.AbstractIvyTriggerByFullContext. I understand this is inelegant, but was preferable to the solution of using reflection to modify the state of AbstractTriggerByFullContext.context from the IvyTrigger class (which in my code extends my modified AbstractIvyTriggerByFullContext). This solution is practical and works for us locally, but I would appreciate advice on how this would best be implemented in the main trunk for ivytrigger-plugin.