<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">(Starting a second reply for a different patch to make it easier to follow with threaded mail clients)<br><br></div>I've a comment in <a href="https://review.openstack.org/#/c/319616/8/jenkins_jobs/builder.py">https://review.openstack.org/#/c/319616/8/jenkins_jobs/builder.py</a> that notes if an application made a call to 'JenkinsManager.update_jobs()' it would be a reasonable expectation that a subsequent call to 'JenkinsManager.delete_old_managed()' should not need to explicitly be passed the list of jobs that were just to the update method.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">For simplicity does it make sense to ensure the following would do the right thing by default:<br><br></div><div class="gmail_extra">jm = JenkinsManager(cfg)<br></div><div class="gmail_extra">jm.update_jobs([list of jobs])<br></div><div class="gmail_extra">jm.delete_old_unmanaged()<br><br></div><div class="gmail_extra">This would require maintaining some internal state in JenkinsManager on the list of jobs updated and then reusing that list in delete_old_unmanaged() unless passed an explicit list of jobs to keep.<br><br></div><div class="gmail_extra">If this were to be supported, should it take the form of:<br><ol><li>Retain the list of the last set of jobs sent to update_jobs(), and overwrite on each call to update_jobs()<br></li><li>Continuously update an internal list of jobs of what has been updated since the JenkinsManager object was created?</li></ol><p><br></p><p>The second one would facilitate multiple calls to update_jobs, but tbh I suspect it's unnecessary complicated. But thought I'd throw it out there.<br></p></div><div class="gmail_extra">At the very least I'm going to fix the method so that a call without passing a list of jobs doesn't cause an exception.<br></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">Darragh Bailey<br>"Nothing is foolproof to a sufficiently talented fool"</div>
</div></div>