Bumping since I feel this is an important discussion. Darragh, Wayne, any thoughts on this one?
Thanks, Thanh On 8 February 2016 at 10:46, Thanh Ha <[email protected]> wrote: > Hi Everyone, > > 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. > > 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. > > So a simple step-by-step example: > > 1. Create a simple job in JJB with just job name and the setting "disabled" > > - job: > name: job-name > disabled: false > > 2. Look at Jenkins UI for the job. It should be in "disabled" state > 3. Delete the line "disabled: false" from your YAML and update the job > again > 4. Look at Jenkins UI for the job. It is still in "disabled" state. > 5. In the Jenkins UI enable the job > 6. Update the job again with JJB and notice the Job is now still "enabled" > this time > > 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. > > 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. > > 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. > > Thoughts? > > Thanh > > [1] https://review.openstack.org/261620/ >
_______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
