| *** caphrim007_ has joined #openstack-jjb | 00:26 | |
| *** caphrim00_ has joined #openstack-jjb | 00:28 | |
| *** caphrim00_ has quit IRC | 00:30 | |
| *** caphrim007 has quit IRC | 00:30 | |
| *** caphrim007 has joined #openstack-jjb | 00:30 | |
| *** caphrim007_ has quit IRC | 00:31 | |
| *** caphrim007 has quit IRC | 00:34 | |
| *** caphrim007 has joined #openstack-jjb | 01:55 | |
| *** caphrim007 has quit IRC | 01:57 | |
| *** mnencia has quit IRC | 03:04 | |
| *** mnencia has joined #openstack-jjb | 03:22 | |
| *** caphrim007 has joined #openstack-jjb | 03:45 | |
| *** caphrim007_ has joined #openstack-jjb | 03:50 | |
| *** caphrim007 has quit IRC | 03:53 | |
| *** caphrim007_ has quit IRC | 04:26 | |
| *** caphrim007 has joined #openstack-jjb | 04:27 | |
| *** caphrim007_ has joined #openstack-jjb | 04:28 | |
| *** caphrim007 has quit IRC | 04:32 | |
| *** Odd_Bloke has quit IRC | 08:24 | |
| *** daniel has joined #openstack-jjb | 08:26 | |
| *** daniel is now known as Guest8611 | 08:27 | |
| *** Guest8611 is now known as Odd_Bloke | 08:27 | |
| *** Odd_Bloke has joined #openstack-jjb | 08:27 | |
| *** hashar has joined #openstack-jjb | 14:49 | |
| *** caphrim007_ has quit IRC | 15:34 | |
| zxiiro | I think we should look into the variable precedence in defaults for the next release. It's a pain point for us right now because the order doesn't make sense imo. | 15:36 |
|---|---|---|
| zxiiro | job-group > project -> job-template > defaults | 15:37 |
| zxiiro | I think it should be project > job-group > defaults > job-template | 15:37 |
| zxiiro | those are the 4 I use but I suspect there's probably other places variables can appear that I'm not aware of. | 15:37 |
| zxiiro | Also it would be nice if we can allow macros to set their own defaults too. | 15:38 |
| electrofelix | zxiiro: on https://review.openstack.org/#/c/533844, originally had this set to True only if a configuration file was found, but that caused issues with the change in the Jenkins permissions model from V2 onwards and therefore switched it to be false by default. Do you think it's ok to go back to that behaviour? I'm a little dubious | 15:48 |
| electrofelix | zxiiro: on the params there are a few combinations depending on what works best: | 15:50 |
| electrofelix | project > job-group > defaults > job-template | 15:50 |
| electrofelix | project > job-group > job-template > defaults | 15:50 |
| electrofelix | project > job-group > named defaults > job-template > global defaults | 15:50 |
| electrofelix | custom | 15:50 |
| zxiiro | electrofelix: actually I'd be totally cool with a custom option too. | 15:50 |
| zxiiro | but yeah I think job-template should definitely be the lowest priority | 15:51 |
| zxiiro | so that if you configure a defaults file it can override it | 15:51 |
| zxiiro | project should always be highest priority imo | 15:51 |
| zxiiro | the middle after that is a little fuzzy for me as I don't use the rest to often. | 15:51 |
| electrofelix | if job-template is the lowest, it means that you cannot override defaults from a template? | 15:52 |
| zxiiro | electrofelix: I think the change 533844 is fine. If there is no configuration that likely means there's no jenkins server url defined so querying would never work in the first place. I think in the past we had query True by default which is fine for me. This is mostly used by tests anyway right? | 15:52 |
| electrofelix | so I'm not following: 'so that if you configure a defaults file it can override it' | 15:52 |
| electrofelix | zxiiro: if you run a dev jenkins instance, the default url it will appear on is http://localhost:8080/ | 15:53 |
| electrofelix | which is in the defaults | 15:53 |
| zxiiro | electrofelix: so we have a defaults.yaml file containing "- defaults:" in our project we use that to set what variables should be the default if no project specified one. We'd like to use it to override what's defined in a job-template because we see defaults.yaml files as system configuration for specific projects. so that's a way for them to globally override job-templates defaults that they don't like. | 15:54 |
| electrofelix | hmm, I think this is why I was starting to lean towards a user definable preference order :P | 15:55 |
| zxiiro | electrofelix: maybe this will make more sense. So we have a shared global-jjb repo containing only job-templates and job-groups that we load as a submodule in all of our different project jenkins instances, we see it kind of like a docker hub for sharing job-templates. For specific instances we use defaults.yaml to set what the local instance defaults should be so needs to override the "common" defaults defined | 15:56 |
| zxiiro | in job-templates. then specific sub-projects can again override that in their local project.yaml files. | 15:56 |
| electrofelix | I would normally like to be able to temporarily override the values within a single template without needing to define a new set of defaults, so that I can continue to use the global defaults, hence my distinction about whether named defaults and global defaults might well be treated separately | 15:56 |
| zxiiro | so global defaults is the defaults named global.... named defaults are the ones you specify in a job-template? | 15:57 |
| electrofelix | zxiiro: think I got it, I suspect people have different use cases so the desired for a different precedence order may be preferred, and yes that's the difference | 15:58 |
| zxiiro | electrofelix: got it. yeah sounds like we both have different use cases that are not compatible. I think the best solution here then would be to allow configuration to set our own custom order. | 15:58 |
| electrofelix | but I can see how that doesn't work well for your suggested setup | 15:58 |
| zxiiro | back to patch 533844. I think setting it False is probably the right default considering Jenkins 2.x issues. What do we need to do to fix that though, as I understand it the other patch we merged to set it to false broke something. | 16:01 |
| electrofelix | I could work with True being the default if we had a graceful handle and continue unless someone provided a setting value that absolutely required the plugins query to work? | 16:08 |
| zxiiro | I see jjb as a non-interactive tool so I don't see any graceful way to handle that. | 16:10 |
| zxiiro | unless we allow true but if it fails continue with false? | 16:10 |
| zxiiro | maybe it can spit out a warning that true failed and it's continuing as false. | 16:10 |
| electrofelix | that's what I was thinking, and optionally have a 'strict' option that disables graceful failure? | 16:11 |
| zxiiro | yeah that would be good for production environments | 16:12 |
| zxiiro | where we don't want ot risk xml changing on us | 16:12 |
| zxiiro | electrofelix: do you know if a job-group can contain another job-group? | 16:13 |
| electrofelix | Or we go with a three-value setting True/False/None, True => require querying, False => disable querying, None (default) => try but don't error on failure? | 16:13 |
| electrofelix | zxiiro: yes, I'm pretty sure it can, and that was one of the issues with the current precedence | 16:14 |
| zxiiro | electrofelix: I like that. no new config and it handles all the caes. | 16:15 |
| zxiiro | electrofelix: hmm nested job-groups does not appear to work for me. | 16:21 |
| electrofelix | zxiiro: I'll have a check, I thought it did work, but maybe that was me thinking about what would be possible to do with nested job groups and param precedence | 16:26 |
| electrofelix | zxiiro: I've had a read of the code, nested job groups won't work with the existing code, but conceptually there is nothing preventing it from being added | 16:39 |
| zxiiro | ok | 16:40 |
| zxiiro | I can work around it so it's not urgent but good to know | 16:41 |
| *** caphrim007 has joined #openstack-jjb | 17:08 | |
| *** caphrim007 has quit IRC | 17:09 | |
| *** caphrim007 has joined #openstack-jjb | 17:10 | |
| *** caphrim007 has quit IRC | 17:11 | |
| *** caphrim007 has joined #openstack-jjb | 17:11 | |
| *** caphrim007 has quit IRC | 17:12 | |
| *** caphrim007 has joined #openstack-jjb | 17:15 | |
| *** caphrim007_ has joined #openstack-jjb | 17:52 | |
| *** caphrim007 has quit IRC | 17:55 | |
| *** electrofelix has quit IRC | 19:09 | |
| *** hashar has quit IRC | 19:38 | |
| *** caphrim007_ has quit IRC | 19:42 | |
| *** caphrim007 has joined #openstack-jjb | 19:42 | |
| *** larainema has quit IRC | 22:32 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!