Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-55939

git-plugin v4.0.0-rc not returning "lastBuiltRevision" in BuildData

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      After upgrading the git-plugin from 3.9.2 to 4.0.0-rc the field "lastBuiltRevision" is missing from the buildData in a projects api/json output.

      URL: https://ci.example.org/view/all/job/Project/api/json?tree=name,lastSuccessfulBuild[number,url,timestamp,result,actions[lastBuiltRevision[SHA1]]],builds[number,url,timestamp,result,actions[lastBuiltRevision[SHA1]]]\{0,20}

      On version 4.0.0-rc:

       

      {
       "_class" : "hudson.model.FreeStyleProject",
       "name" : "Project",
       "builds" : [
       {
       "_class" : "hudson.model.FreeStyleBuild",
       "actions" : [
       {
       "_class" : "hudson.model.ParametersAction"
       },
       {
       "_class" : "hudson.model.CauseAction"
       },
       {
       "_class" : "hudson.plugins.git.util.BuildDetails"
       },
       {
       "_class" : "hudson.plugins.git.GitTagAction"
       },
       {
      },
       {
      },
       {
      },
       {
      },
       {
      },
       {
      }
       ],
       "number" : 42,
       "result" : "SUCCESS",
       "timestamp" : 1549043593728,
       "url" : "https://ci.example.org/view/all/job/Project/42/"
       },
       # ...truncated...
       ]
      }
      

       

      On version 3.9.2 the output includes the following:

       

      {
       "_class" : "hudson.plugins.git.util.BuildData",
       "lastBuiltRevision" : {
       "SHA1" : "11112222333344445555666777788889999f561"
       }
       },

       

       

      The "Version 4.0.0-rc (January 30, 2019)" changelog is referencing the following:

      •    Stop bloating build.xml files with BuildData (JENKINS-19022)

      Perhaps that's related to the issue.

       

       

        Attachments

          Issue Links

            Activity

            Hide
            markewaite Mark Waite added a comment -

            Resolved in git plugin 4.0.0-beta10

            Show
            markewaite Mark Waite added a comment - Resolved in git plugin 4.0.0-beta10
            Hide
            markewaite Mark Waite added a comment -

            I've created an end to end test case in my jenkins-bugs repository to track the fix.

            I still need to create an automated test in the git plugin itself, but the end to end case provides at least one automated check of the problem.

            My current plan is that git plugin 4.0.0 won't have the JENKINS-19022 fix. It is unfortunate, but I don't see how to include the JENKINS-19022 fix and retain compatibility with git plugin 3.

            Show
            markewaite Mark Waite added a comment - I've created an end to end test case in my jenkins-bugs repository to track the fix. I still need to create an automated test in the git plugin itself, but the end to end case provides at least one automated check of the problem. My current plan is that git plugin 4.0.0 won't have the JENKINS-19022 fix. It is unfortunate, but I don't see how to include the JENKINS-19022 fix and retain compatibility with git plugin 3.
            Hide
            jekeller Jacob Keller added a comment -

            Hmm.. The buildDetails section should include the revision that was built by that build...

            we won't actually have exposed buildData anymore, because this was being duplicated and stored for every build kept...

            Show
            jekeller Jacob Keller added a comment - Hmm.. The buildDetails section should include the revision that was built by that build... we won't actually have exposed buildData anymore, because this was being duplicated and stored for every build kept...
            Hide
            ilendir Stefan Hengelein added a comment -

            Baptiste Mathus Very correct. Sorry for that. As you've said, if you're searching for the culprit in an issue like this for quite some time can be very frustrating. But it is not the first time that something major breaks, but rather every second or third update requires a few days to get everything working again. And then reading the Priority "Minor" is quite funny

            But again, sorry for the Phrasing Mark Waite!

             

            Thanks for the explanation. I was wondering about the -rc suffix as well but assumed it may have been an oversight and should stand for the release version past all release candidates.
            Yes, reverting to the older version fixed everything.

            Show
            ilendir Stefan Hengelein added a comment - Baptiste Mathus Very correct. Sorry for that. As you've said, if you're searching for the culprit in an issue like this for quite some time can be very frustrating. But it is not the first time that something major breaks, but rather every second or third update requires a few days to get everything working again. And then reading the Priority "Minor" is quite funny But again, sorry for the Phrasing Mark Waite !   Thanks for the explanation. I was wondering about the -rc suffix as well but assumed it may have been an oversight and should stand for the release version past all release candidates. Yes, reverting to the older version fixed everything.
            Hide
            batmat Baptiste Mathus added a comment -

            Stefan Hengelein please watch out how you phrase your requests/comments. We understand your frustration, but using such phrasing in unacceptable. This is not a customer support channel.
            Mark is doing the maintenance of the git plugins on personal time, and is doing an absolute great job. I know no other OSS maintainer who literally have many machines and OSes to test his work.

            The issue here is also that there was a misunderstanding, that release was expected to land only in the experimental update center but -rc was used instead of -alpha and -beta (which are the only suffices automatically exposed under the experimental UC, instead of the main one). These -rc releases are in the process of being hidden right now.

            Please revert anyway in the meantime.

            Show
            batmat Baptiste Mathus added a comment - Stefan Hengelein please watch out how you phrase your requests/comments. We understand your frustration, but using such phrasing in unacceptable. This is not a customer support channel. Mark is doing the maintenance of the git plugins on personal time, and is doing an absolute great job. I know no other OSS maintainer who literally have many machines and OSes to test his work. The issue here is also that there was a misunderstanding, that release was expected to land only in the experimental update center but -rc was used instead of -alpha and -beta (which are the only suffices automatically exposed under the experimental UC, instead of the main one). These -rc releases are in the process of being hidden right now. Please revert anyway in the meantime.
            Hide
            ilendir Stefan Hengelein added a comment -

            Thanks. Now I know why our jenkins is trying to rebuild over 3k builds after the update. Very well done guys, very well done.

            This is not a Minor problem but rather a MAJOR one.

            Show
            ilendir Stefan Hengelein added a comment - Thanks. Now I know why our jenkins is trying to rebuild over 3k builds after the update. Very well done guys, very well done. This is not a Minor problem but rather a MAJOR one.
            Hide
            markewaite Mark Waite added a comment -

            Tom de Vries , thanks for the report. I won't be able to investigate this for at least a week due to limited internet access while I'm on personal travel. Possibly jacob-keller will be able to review it before then.

            Justin Pihony I don't understand how your phrase

            if you use a regex then it causes each push to re-find all matching builds and re-build them all

            is related to this report. Can you provide more details to clarify why you believe that the use of a regex (in what context?) is related to a REST API call? If are confident that what you're observing is related to the REST API, please clarify and provide more details to duplicate the problem. Otherwise, submit a new bug report with additional details that will allow others to duplicate the bug.

            Show
            markewaite Mark Waite added a comment - Tom de Vries , thanks for the report. I won't be able to investigate this for at least a week due to limited internet access while I'm on personal travel. Possibly jacob-keller will be able to review it before then. Justin Pihony I don't understand how your phrase if you use a regex then it causes each push to re-find all matching builds and re-build them all is related to this report. Can you provide more details to clarify why you believe that the use of a regex (in what context?) is related to a REST API call? If are confident that what you're observing is related to the REST API, please clarify and provide more details to duplicate the problem. Otherwise, submit a new bug report with additional details that will allow others to duplicate the bug.
            Hide
            justinpihony Justin Pihony added a comment -

            We just ran into this issue and it is a showstopper for us. It seems that if you use a regex then it causes each push to re-find all matching builds and re-build them all.

            Show
            justinpihony Justin Pihony added a comment - We just ran into this issue and it is a showstopper for us. It seems that if you use a regex then it causes each push to re-find all matching builds and re-build them all.

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              tomdev Tom de Vries
              Votes:
              4 Vote for this issue
              Watchers:
              10 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: