On 15 February 2016 at 15:02, David Caro <[email protected]> wrote: > On 02/15 09:48, Thanh Ha wrote: >> Bumping since I feel this is an important discussion. Darragh, Wayne, any >> thoughts on this one?
Sorry only catching up now. Had started a draft response via my phone over the weekend :-\ >> On 8 February 2016 at 10:46, Thanh Ha <[email protected]> wrote: >> >> > Hi Everyone, >> > It appears that if you update Jenkins with missing XML, it's behaviour >> > will be to leave the field untouched as in whatever was configured last >> > will remain the setting in Jenkins. Have encountered this with the hipchat plugin XML, so aware of how annoying it can be. Ultimately I think the code for the newer version of plugins was modified to use defaults for the new settings in the future since it was just too surprising in usage. >> > I feel like there shouldn't be optional settings in JJB but instead if a >> > user does not pass a configuration step then JJB should always set a >> > default for said setting so that the result is more deterministic. When I >> > remove a job configuration from YAML my expectation is that Jenkins will >> > revert the setting back to whatever the default state is rather than >> > Jenkins leaving the previous state. >> > >> > We could potentially resolve this via work on patch [1] if there's >> > agreement that the behaviour on the behaviour of JJB when a setting is not >> > provided in YAML. My opinion is that instead of optional all parameters >> > should have a default setting. Might want to ping the Jenkins dev mailing list first to get the full set of rules about how Jenkins updates job configuration, because this occurs in some cases and not in others. I suspect it's to do with the parent tag type, so if it's a simple data container like a list, the contents are placed with exactly as defined by the XML, but if it's a custom tag it is either merged, or depends on how the plugin/code wishes to handle the changes. Still a good idea to know exactly what the rules are. > What happens then when you want to leave the setting with it's current value? > > Let me put an example, in my team we use to leave notes in the jobs > descriptions and also manually disable/enable jobs. That is useful when > troubleshooting jobs, imagine that you have a job that cleans up the workspace > on start, and it's failing, what we do is disable the job, so it does not > cleanup the workspace and then we add a small comment in the description with > a > note on who's working on the job and why (if the reason for the failure is > known). Be willing to treat 'disabled' as a special case here, as for most other XML tags the current behaviour of remove yaml setting and it keeps the original value stored is quite a surprising behaviour. > We don't want to do so by yaml, as most probably is just one of the jobs > generated by a matrix of combinations and that means that we would have to > add a lot of boilerplate code just to be able to disable that specific > job. And the debugging is transient, not meant to last more than a few hours. > > In that case, if you force jjb to send a default value all the time, that flow > would stop working. JJB already retrieves basic job information from the remote jenkins before updating, so in theory it would be possible to allow special handling of the disabled XML tag by checking if the job is disabled or not in the information returned (assuming we don't discard all of the extra info). > I think that if you want to set defaults, you should do so in the default > construct instead, that also prevents that any change in the defaults on jjb > code from changing the generated xml. The deeper you go in the various plugin settings the more complex this becomes. At worst you end up needing to define everything explicitly for each job via different sets of defaults, thus removing the benefit of 'optionals' anyway. Probably also requires deep merging of defaults to work correctly in order to be usable without being onerous. >> > >> > Thanh >> > >> > [1] https://review.openstack.org/261620/ > -- > David Caro Think it all comes down to the following: * Need to understand what exactly is happening within Jenkins with regard to XML updating, clearly not just taking the XML given and changing to match that, more likely some kind of merge is going on. * Is the sort of workflow described by David limited to the disabled tag, or useful elsewhere? If limited I think we should handle 'disabled' as a special case. * If the decision is to change behaviour going forward, initially needs to only apply to new settings being added and have a way of converting existing code while matching existing behaviour via some setting. Expect we'll have to support existing use of optionals for at least one major release for the current modules whether we decide to switch the behaviour for the future or not. So the change identified will have to keep that in consideration. -- Darragh Bailey "Nothing is foolproof to a sufficiently talented fool" _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
