CasC backward compatibility

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

CasC backward compatibility

nicolas de loof-2
I've been exploring some backward compatibility support in Configuration-as-Code.

As a reminder, CasC plugin doesn't define a configuration model, but introspect Jenkins live instance to discover configurable attributes (replicating UI databinding). Issue happens when some refactoring significantly change this model. A previously valid jenkins.yaml configuration would then not be able to load, with some cryptic error message (which we also try to improve).

Oleg discovered such a breaking change with JNLPLauncher, as a new workingDir required constructor parameter has been introduced. This arguably could have been implemented without such a break, but the topic here is to understand how we could still load configuration file to maintain Jenkins master configuration valid, and report obsolete data.

The main idea is for CasC to be able to still use a legacy constructor which used to be the @DataBoundConstructor on previous version, and we can assume to manage backward compatibility + data conversion.

Sample typical scenario: 

foo-plugin v1.0:
@DataBoundConstructor
public Foo(Secret key, Secret token) { ... }

foo-plugin v2.0:
@Deprecated
public Foo(Secret key, Secret token) { this(convert(key, token)); }


@DataBoundConstructor
public Foo(String credentialsId) { ... }

From CasC we want to be able to still use Foo(Secret,Secret) with provided configuration and report a deprecation warning to end-user.

Oleg proposal for such scenario is here, please give us your feedback:

As discussed with Oleg, to reduce maintenance effort we could reduce this to some metadata to only list the Constructor signatures that should be considered for backward compatibility.



On my side I've investigated support for attribute names while a @Symbol annotation is added to offer a "better name", but we still want to support the legacy one.

Typical scenario did already happened here as @Symbol got a new preferred ("canonical") value added.

@Extension @Symbol({"dumb",
+ "slave", "agent" /*because this is in effect the canonical slave type*/})

My proposal to handle this scenario is here : https://github.com/jenkinsci/configuration-as-code-plugin/pull/256 (here again, review and suggestions are welcome). It also add support fo CasC to report the source file + line number for a configuration element and assist end-user in fixing configuration mistakes.





 

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzkXvsyykaoQsuF%3DX7XqgbQOFxfZN8ivEVKhek685tpPNw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.