Deserialization failing for field changeSet in BuildWithDetails

[holgpar]

Greetings,

I noticed that the the field changeSet in class BuildWithDetails is always null, even if present in the json data of the build. One reason seem to be that the actual json key is named 'changeSets' (with plural 's' at the end):

...
 "changeSets" : [
    {
      "_class" : "hudson.plugins.git.GitChangeSetList",
      "items" : [
        {
          "_class" : "hudson.plugins.git.GitChangeSet",
          "affectedPaths" : [
            "README.md"
          ],
          "commitId" : "ba40ff32c60f692918c1d51f5c80842124ed04af",
          "timestamp" : 1519306808000,
          "author" : {
            "absoluteUrl" : "https://myjenkins/user/holger.partsch",
            "fullName" : "holger.partsch"
          },
          "authorEmail" : "holger.partsch@sap.com",
          "comment" : "longer\ncommit message\n",
          "date" : "2018-02-22 13:40:08 +0000",
          "id" : "ba40ff32c60f692918c1d51f5c80842124ed04af",
          "msg" : "longer",
          "paths" : [
            {
              "editType" : "edit",
              "file" : "README.md"
            }
          ]
        }
      ],
      "kind" : "git"
    }
  ],
...

Another problem is that changeSets is actually a json array. In later version of jackson, there is a way to deal with that, using the feature DeserializationFeature.UNWRAP_SINGLE_VALUE_ARRAYS.

I can do a pull request, but I would prefer to upgrade to latest jackson, if there is no reason against hat.

Many thanks, Holger

[khmarbaise]

I would appreciate a PR but I would suggest to make on PR with upgrade to latest Jackson and see if everything is working and afterwards you can make one with the suggestions above..and it would be great to make appropriate issue before...

[holgpar]

Thanks for the swift reply. I looked at the problem more closely and it turned out that what I have stated is only valid for pipeline builds. For those, the api indeed has a json array called changeSets whereas Freestyle builds have a singe changeSet.

This small deviation does not really warrant to introduce a set of classes Pipeline{Job,Build,WithDetails...}. I would rather introduce a further field and a further Getter to handle the array case. What do you think?

[khmarbaise]

Ah that's what I expected. The part for pipeline is a way to go so I would like not to see supplemental getters...better might be going direction to pipeline..where already already requested for (can't remember the issue right now)...But you might take a short path at the beginning...and go for getters ...