<div dir="ltr">Bumping since I feel this is an important discussion. Darragh, Wayne, any thoughts on this one?<div><br></div><div>Thanks,</div><div><br></div><div>Thanh</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 8 February 2016 at 10:46, Thanh Ha <span dir="ltr"><<a href="mailto:thanh.ha@linuxfoundation.org" target="_blank">thanh.ha@linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Everyone,<div><br></div><div>I'd like to discuss the usefulness of optional parameters in JJB. We've been hit by a behaviour that is in my opinion indeterministic and causes confusion as well as inconvenience as a user. I was reminded by this in discussions in this patch [1] but then again this weekend while we were trying to move to a Zuul setup.</div><div><br></div><div>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.</div><div><br></div><div>So a simple step-by-step example:</div><div><br></div><div>1. Create a simple job in JJB with just job name and the setting "disabled"</div><div><pre style="padding:5px;color:rgb(51,51,51);line-height:15.6px;border-top-width:1px;border-bottom-width:1px;border-style:solid none;border-top-color:rgb(170,204,153);border-bottom-color:rgb(170,204,153);background-color:rgb(238,255,204)">- job:
    name: job-name
    disabled: false</pre></div><div>2. Look at Jenkins UI for the job. It should be in "disabled" state<br></div><div>3. Delete the line "disabled: false" from your YAML and update the job again</div><div>4. Look at Jenkins UI for the job. It is still in "disabled" state.</div><div>5. In the Jenkins UI enable the job</div><div>6. Update the job again with JJB and notice the Job is now still "enabled" this time</div><div><br></div><div>So this means if we don't pass an XML setting to Jenkins it will always leave the job configuration in the last state that was configured. I feel like this result with JJB is indeterministic with this behaviour and affects any code that does not create XML for a configuration setting if it is not configured in YAML.</div><div><br></div><div>We were hit again by this issue over the weekend while trying to migrate our jobs over to Zuul by removing the Gerrit Trigger configurations in JJB.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Thoughts?</div><div><br></div><div>Thanh</div><div><br></div><div>[1] <a href="https://review.openstack.org/261620/" target="_blank">https://review.openstack.org/261620/</a></div></div>
</blockquote></div><br></div>