[OpenStack-Infra] JJB V2.0 planning
Darragh Bailey
daragh.bailey at gmail.com
Tue Nov 15 16:20:11 UTC 2016
(Starting a second reply for a different patch to make it easier to follow
with threaded mail clients)
I've a comment in
https://review.openstack.org/#/c/319616/8/jenkins_jobs/builder.py 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.
For simplicity does it make sense to ensure the following would do the
right thing by default:
jm = JenkinsManager(cfg)
jm.update_jobs([list of jobs])
jm.delete_old_unmanaged()
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.
If this were to be supported, should it take the form of:
1. Retain the list of the last set of jobs sent to update_jobs(), and
overwrite on each call to update_jobs()
2. Continuously update an internal list of jobs of what has been updated
since the JenkinsManager object was created?
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.
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.
--
Darragh Bailey
"Nothing is foolproof to a sufficiently talented fool"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20161115/3bbcb9ea/attachment.html>
More information about the OpenStack-Infra
mailing list