*** abelur has quit IRC | 02:32 | |
*** abelur has joined #openstack-jjb | 02:35 | |
*** openstackgerrit has quit IRC | 06:47 | |
*** hashar has joined #openstack-jjb | 08:00 | |
*** electrofelix has joined #openstack-jjb | 09:59 | |
*** ssbarnea has quit IRC | 11:11 | |
*** ssbarnea has joined #openstack-jjb | 11:14 | |
*** abelur has quit IRC | 12:50 | |
*** abelur has joined #openstack-jjb | 12:51 | |
*** smyers has quit IRC | 13:13 | |
*** hashar has quit IRC | 14:37 | |
*** hashar has joined #openstack-jjb | 14:37 | |
*** hashar is now known as hasharAway | 15:46 | |
*** hasharAway is now known as hashar | 18:43 | |
*** hashar has quit IRC | 19:06 | |
*** hashar has joined #openstack-jjb | 19:15 | |
*** openstack has joined #openstack-jjb | 20:33 | |
*** ChanServ sets mode: +o openstack | 20:33 | |
*** electrofelix has quit IRC | 21:04 | |
*** electrofelix has joined #openstack-jjb | 21:05 | |
electrofelix | zxiiro waynr: so I've been digging into the expansion issue, and it's not quite as easy as I first thought | 21:06 |
---|---|---|
zxiiro | electrofelix: do we want to roll back? | 21:06 |
electrofelix | might just need to sound some things out | 21:07 |
zxiiro | electrofelix: ok. well I do have a rollback patch already prepared since I've been using it on my own system. (it's not trivial to revert since we merged other patches since). So I can push that up if you'd like. | 21:08 |
*** openstack has joined #openstack-jjb | 21:13 | |
*** ChanServ sets mode: +o openstack | 21:13 | |
electrofelix | I think the work in expanding macros was to allow use of template data to be applied to macros without needing to pass through data defined at each level | 21:14 |
electrofelix | a macro could reference a param provided by a project definition without needing an explicit reference in the job to set the same param via passthru | 21:15 |
electrofelix | does that sound right? or am I mistaken? | 21:15 |
electrofelix | should probably document how this should work in detail | 21:15 |
electrofelix | so either we load up all entrypoints first, read in the expansion information from modules (set via decorators) and then use that to expand the job by substituting in the macro with params before converting from yaml to xml | 21:17 |
electrofelix | or we attach all params to be passed down to modules to be used with delayed macro expansion at conversion time | 21:18 |
electrofelix | however I though the entire purpose of the refactoring was to avoid that so the modules could act as a straight conversion from yaml to xml | 21:19 |
electrofelix | so that would seem to suggest the first option would be preferable | 21:19 |
zxiiro | Maybe waynr should comment when he's around ^ | 21:23 |
*** openstackgerrit has joined #openstack-jjb | 21:40 | |
openstackgerrit | Michael Jeanson proposed openstack-infra/jenkins-job-builder master: Add messages and categories ignores to warnings publisher https://review.openstack.org/528092 | 21:40 |
electrofelix | waynr: when you get a chance, does changing the ModuleRegistry to provide additional data to be used by the parser for additional expansion points make sense? | 21:51 |
electrofelix | that would then need to be used by expand_macros to expand on encountering any job definition that contains those items. Seems like it could be quite expensive to have to walk the data for any points that would trigger expansion | 21:51 |
electrofelix | hoping there might be a slightly better way | 21:52 |
*** electrofelix has quit IRC | 21:52 | |
*** hashar has joined #openstack-jjb | 22:10 | |
*** hashar has quit IRC | 22:18 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!