How to deal with class update and serialization of Jenkins configurations

[Goyot, Martin]

Hi there,

We made a mistake while implementing our plugin and operated a change on what seems to be a serializable class. Here is the class (https://github.com/jenkinsci/tuleap-git-branch-source-plugin/blob/master/src/main/java/org/jenkinsci/plugins/tuleap_git_branch_source/TuleapSCMNavigator.java) and here are the incriminated changes (https://github.com/jenkinsci/tuleap-git-branch-source-plugin/pull/229/files) and (https://github.com/jenkinsci/tuleap-git-branch-source-plugin/pull/234/files) where the class attribute `projectId` was renamed to `tuleapProjectId` for TuleapSCMNavigator.

How can we solve this ? Because now the issue is that every job previously created can't be opened with the new version of the plugin because of this attribute renaming. Is there a way in Jenkins to deal with such updates of classes ? I imagine that this is something that can happen quite often when adding new features, because if we add a new attribute we might end up with the same problem. 

Sorry if I missed anything in the documentation and thanks in advance,

Martin

[James Nord]

PR 229 only seemed to change the jelly - the persisted data (if no one saved it) is still looking like it is using the old projectId so existing things should still work, but newly saved configuration would likely not persist correctly.

Change the Jelly option back to projectId and also change the parameter in the doCheck method and then I think things should start working again.

--
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2Bb6JB-2S883fgAZTrKxrooGrwXWGRBEOj2jqLHHBe1G41zLvQ%40mail.gmail.com.

[Goyot, Martin]

Hi James,

Although PR 229 is only changing the jelly, PR 234 does indeed change the attribute's name in the TuleapSCMNavigator class. So I don't think reverting back would work, and it would also not solve the problem of jobs created using the new version of the plugin. Or am I missing something, cause it's very likely.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPzq3pdzjUhKp5HX72s9fiTKhcCk6PY7aZLfOB02qp%2BCZhnN7Q%40mail.gmail.com.

[Jesse Glick]

On Mon, Oct 11, 2021 at 10:51 AM Goyot, Martin <martin...@enalean.com> wrote:

Is there a way in Jenkins to deal with such updates of classes ?

Typically solvable by adding a `readResolve` method. You are advised to verify correctness using a `JenkinsRule` test making use of `@LocalData`. 

[Goyot, Martin]

Hi Jesse,

Thanks for your input. I agree with the readResolve but then I'm wondering about the maintainability of the class. Let's say in a future version I add another field, and in a next one yet another. My readResolve is going to be huge and complicated to deal with. Is there some kind of pattern to do it right ?

Best regards,

Martin

--

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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1uDnj4Lvg3ZL7_u3o1W%2BtDqo983Nyv3H3MucteFO7Z6g%40mail.gmail.com.

[Daniel Beck]

On Tue, Oct 12, 2021 at 10:14 AM Goyot, Martin <martin...@enalean.com> wrote:

Thanks for your input. I agree with the readResolve but then I'm wondering about the maintainability of the class. Let's say in a future version I add another field, and in a next one yet another. My readResolve is going to be huge and complicated to deal with. Is there some kind of pattern to do it right ?

In general the pattern is to just not rename fields.

Adding new fields doesn't need readResolve support unless you want a different value than the default (0, false, null). This is why new options are often phrased so the legacy default behavior corresponds to the default field value ("dontDoWhatever" field names are common).

[Goyot, Martin]

Got it, thanks for all your inputs !

--
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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7Pt%2BzNKUL_wa66GYkrsQ3ja%3D85OdddSODjv29QTjRMmCycw%40mail.gmail.com.

[Jesse Glick]

On Tue, Oct 12, 2021 at 6:07 AM 'Daniel Beck' via Jenkins Developers <jenkin...@googlegroups.com> wrote:

new options are often phrased so the legacy default behavior corresponds to the default field value ("dontDoWhatever" field names are common).

To be clear, use of the negative sense makes for terrible UI and confusing APIs, so your public interfaces should refer to a `doWhatever` / “Do Whatever” property if at all possible—just encapsulate the backwards field.

If you do want to name the field intuitively, it is typical to introduce for example a `Boolean` field where `null` is converted to `true` either in `readResolve` or on demand in a getter.

Note that the `configuration-as-code` plugin deals with public constructor/getter/setter pairs, as does Pipeline when defining steps, unlike the `config.xml` XStream storage used on disk and also in some REST(ish) APIs and CLI commands which deals with fields and the serial form.