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

After Jenkins updated to ver. 2.60.1 Caused: com.google.common.util.concurrent.UncheckedExecutionException

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Critical Critical
    • core
    • Jenkins ver. 2.60.1
      master - jdk1.8.0_112, Windows2008R2
      slave - jdk1.8.0_112, RHEL 6.5

      git-plugin does not cause this error

      Git plugin:
      Global Config user.name Value - null
      Global Config user.email Value - null
      Create new accounts based on author/committer's email - False

      1. Prerequisite:

      master Jenkins ver. 2.43 , jdk1.8.0_112, Windows2008R2
      slave1 - jdk1.7.0_51, RHEL 6.5
      slave2 - jdk1.7.0_51, RHEL 6.5

      2. Create:
      job1 Freestyle project(For Example: Empty job or add Shell Execute Block: sleep 300, gradle build)

      3. Update Jenkins:
      master to ver. 2.60.1, jdk1.8.0_112
      slave1 - slave.jar, jdk1.8.0_112
      slave2 - slave.jar, jdk1.8.0_112

      4. Configure slaves:
      Jenkins->Nodes->slave1->Configure->Labels: LabelRunJob
      Jenkins->Nodes->slave2->Configure->Labels: LabelRunJob

      5. Configure job1:
      Jenkins->View1->job1->Configure->Enable "This project is parameterized":
      Add Label:
      Name: LabelRunJob
      Default Value: LabelRunJob
      Disable "Run on all nodes matching the label"

      6. Run job1 on slaves(parallel run job)
      After 10-50 success build, get:
      Caused: com.google.common.util.concurrent.UncheckedExecutionException

      Workarщund:
      Create new job2 copy from job1
      or
      Create new Node slave3 copy from slave1
      and
      Create new Node slave4 copy from slave2

      Log and build.xml in attach

        1. build_without_git-plugin.xml
          4 kB
        2. build.xml
          8 kB
        3. Log_without_git-plugin.txt
          2 kB
        4. Log.txt
          2 kB

          [JENKINS-46990] After Jenkins updated to ver. 2.60.1 Caused: com.google.common.util.concurrent.UncheckedExecutionException

          Mark Waite added a comment -

          I have been running Jenkins 2.60.1 (and later) since its release in various environments and have not seen this problem.  It appears to be deep in the Jenkins core classes related to users.

          Can you provide detailed steps to duplicate the problem?

          For example, I see that your master is running on Windows.  I run my masters on Linux variants, with Windows agents.  Are there any conditions which might make your Jenkins installation exceptional?

          Mark Waite added a comment - I have been running Jenkins 2.60.1 (and later) since its release in various environments and have not seen this problem.  It appears to be deep in the Jenkins core classes related to users. Can you provide detailed steps to duplicate the problem? For example, I see that your master is running on Windows.  I run my masters on Linux variants, with Windows agents.  Are there any conditions which might make your Jenkins installation exceptional?

          Daniel Beck added a comment -

          The description is unclear. Why is the agent label relevant here? What does "Recreate job is help on 1-2 day" mean? That starting over with a new job without build history is a successful workaround?

          Please provide the build.xml and other metadata for the affected build.

          Daniel Beck added a comment - The description is unclear. Why is the agent label relevant here? What does "Recreate job is help on 1-2 day" mean? That starting over with a new job without build history is a successful workaround? Please provide the build.xml and other metadata for the affected build.

          Daniel Beck added a comment -

          Git Plugin does not appear to gracefully handle the case when csAuthorEmail is null, and createAccountBasedOnEmail is true.

          https://github.com/jenkinsci/git-plugin/blob/815a0159f3c84f370ee2e6b47a4fbfd11c1cc32e/src/main/java/hudson/plugins/git/GitChangeSet.java#L359

          It's not clear to me whether the distinction between author and committer in parsing the changelog might be related as well.


          Please provide:

          • The value of the global option that determines whether Git Plugin uses email addresses as users
          • The value of the job config option that determined whether Git Plugin uses committer or author as metadata
          • The stored changelogs of the job in question
          • The recent Git history metadata of the repositories used by the job in question

          Daniel Beck added a comment - Git Plugin does not appear to gracefully handle the case when  csAuthorEmail is null , and createAccountBasedOnEmail is true . https://github.com/jenkinsci/git-plugin/blob/815a0159f3c84f370ee2e6b47a4fbfd11c1cc32e/src/main/java/hudson/plugins/git/GitChangeSet.java#L359 It's not clear to me whether the distinction between author and committer in parsing the changelog might be related as well. Please provide: The value of the global option that determines whether Git Plugin uses email addresses as users The value of the job config option that determined whether Git Plugin uses committer or author as metadata The stored changelogs of the job in question The recent Git history metadata of the repositories used by the job in question

          Daniel Beck added a comment -

          The line information of Git Plugin indicates it's actually the line with csAuthor (rather than csAuthorEmail), but the bug report doesn't even mention the plugin version.

          Daniel Beck added a comment - The line information of Git Plugin indicates it's actually the line with csAuthor (rather than csAuthorEmail), but the bug report doesn't even mention the plugin version.

          edited description

          Vitaly Zolotorevsky added a comment - edited description

          Daniel Beck added a comment -

          git-plugin does not cause this error

          Interesting. The stack trace still says

           at hudson.plugins.git.GitChangeSet.getAuthor(GitChangeSet.java:452)

          and the build.xml contains

            <scm class="hudson.plugins.git.GitChangeLogParser" plugin="git@3.5.0">
              <authorOrCommitter>false</authorOrCommitter>
            </scm>

          So something is going on here.

          Daniel Beck added a comment - git-plugin does not cause this error Interesting. The stack trace still says  at hudson.plugins.git.GitChangeSet.getAuthor(GitChangeSet.java:452) and the build.xml contains   <scm class="hudson.plugins.git.GitChangeLogParser" plugin="git@3.5.0">     <authorOrCommitter>false</authorOrCommitter>   </scm> So something is going on here.

          Vitaly Zolotorevsky added a comment - - edited

          if run job without git-plugin whatever get error

          Vitaly Zolotorevsky added a comment - - edited if run job without git-plugin whatever get error

          add Log and build.xml without using git-plugin

          Vitaly Zolotorevsky added a comment - add Log and build.xml without using git-plugin

          Daniel Beck added a comment -
          at hudson.plugins.git.GitChangeSet.findOrCreateUser(GitChangeSet.java:379)
          at hudson.plugins.git.GitChangeSet.getAuthor(GitChangeSet.java:452)

          It's still being called.

          Nobody's claiming you're manually configuring it, but undoubtedly it's still being used.

          Daniel Beck added a comment - at hudson.plugins.git.GitChangeSet.findOrCreateUser(GitChangeSet.java:379) at hudson.plugins.git.GitChangeSet.getAuthor(GitChangeSet.java:452) It's still being called. Nobody's claiming you're manually configuring it, but undoubtedly it's still being used.

          Daniel Beck added a comment -

          However, it looks like the job in question had Git SCM configured in the past. Specifically, in older build.xml after the previous successful build. So if the same job ever had Git configured, that could be enough for this to be triggered.

          Daniel Beck added a comment - However, it looks like the job in question had Git SCM configured in the past. Specifically, in older build.xml after the previous successful build. So if the same job ever had Git configured, that could be enough for this to be triggered.

            Unassigned Unassigned
            zolotorevsky Vitaly Zolotorevsky
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: