• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • git-plugin
    • None

      I have a git job that builds all branches except master. I have the job setup to send email to only the committers using email-ext. The idea being that developers can push their branches to the CI server and then get feedback on if all tests work in the production environment. When a new branch is pushed to the server the build runs and no emails are sent. I'm using version 1.1.19 of the bit plugin, a 2.22 debug version of the email-ext plugin on Jenkins version 1.470. The debug output from the email-ext plugin shows:
      20:43:27 [WARNINGS] Parsing warnings in console log with parser Java Compiler (javac)
      20:43:27 Archiving artifacts
      20:43:29 Publishing Cobertura coverage report...
      20:43:29 Publishing Cobertura coverage results...
      20:43:34 Recording test results
      20:43:35 Description set: Branch origin/feature.create-tournament-on-import
      20:43:36 Email was triggered for: Success
      20:43:36 Sending email for trigger: Success
      20:43:36 Send to developers
      20:43:36 Getting users from changeset
      20:43:36 Get users from changeset - users.size() = 0
      20:43:36 413: recipientAddresses.size() = 0
      20:43:36 Setting 0 recipients
      20:43:36 An attempt to send an e-mail to empty list of recipients, ignored.
      20:43:36 Finished: SUCCESS

      The changeset in Jenkins is indeed empty, although I would think this should show the changes from master or where the branch was created.

          [JENKINS-14138] New git branch has empty changelist

          jpschewe created issue -

          Alex Earl added a comment -

          What does the changes list on the build page show? If there is nothing there, then the email-ext plugin can't get at it either as the build information is taken from the changes of the scm for the build. So, if the changeset is empty, there is nothing email-ext can do.

          Alex Earl added a comment - What does the changes list on the build page show? If there is nothing there, then the email-ext plugin can't get at it either as the build information is taken from the changes of the scm for the build. So, if the changeset is empty, there is nothing email-ext can do.

          jpschewe added a comment -

          Yes, the changelist is empty. I tagged both plugins as I wasn't sure if there was something that email-ext can do with the git plugin to get this resolved.

          jpschewe added a comment - Yes, the changelist is empty. I tagged both plugins as I wasn't sure if there was something that email-ext can do with the git plugin to get this resolved.

          Alex Earl added a comment -

          If there are no changes on the branch you are building, why would you expect the changeset to have entries?

          Alex Earl added a comment - If there are no changes on the branch you are building, why would you expect the changeset to have entries?

          jpschewe added a comment - - edited

          Assume the following:

                A---B---C topic
               /
          D---E---F---G master
          

          The last build was of E. I push the branch topic to the server and it is built. I would expect the changeset for this build to contain A, B, C. Instead it's empty. My commit hook script sends me email that these are the new changes, I would expect my CI system to do the same and notify the committers of A, B and C if those changes passed CI.

          jpschewe added a comment - - edited Assume the following: A---B---C topic / D---E---F---G master The last build was of E. I push the branch topic to the server and it is built. I would expect the changeset for this build to contain A, B, C. Instead it's empty. My commit hook script sends me email that these are the new changes, I would expect my CI system to do the same and notify the committers of A, B and C if those changes passed CI.

          Alex Earl added a comment -

          This is definitely something with the git plugin then, it has nothing to do with email-ext at this point.

          Alex Earl added a comment - This is definitely something with the git plugin then, it has nothing to do with email-ext at this point.
          Alex Earl made changes -
          Component/s Original: email-ext [ 15538 ]
          Assignee Original: Alex Earl [ slide_o_mix ] New: Nicolas De Loof [ ndeloof ]

          tsondergaard added a comment -

          I'm seeing a similar problem. I am using the git plugin with a <mergeTarget> configured. It is therefore quite typical for devs to check in temporary branches that git then merges to the <mergeTarget> branch and pushes back to the central repo. As it is now this means that jenkins doesn't send emails in the case of a build failure for such new branches.

          I've noticed in the console output from builds on new branches that the git-plugin writes

          No change to record in branch XXX

          This is written by the git-plugin if it cannot find a previous build. In the case where a job is configured with a mergeTarget I believe that the right solution is either

          1. always use <mergeRemote>/<mergeTarget> as the previous ref or
          2. Look for a previous build for the branch first and then fall back to <mergeRemote>/<mergeTarget>

          The names <mergeRemote> and <mergeTarget> are from the config.xml file, where I for example have:

          <userMergeOptions>
          <mergeRemote>origin</mergeRemote>
          <mergeTarget>release/5.0.0</mergeTarget>
          </userMergeOptions>

          tsondergaard added a comment - I'm seeing a similar problem. I am using the git plugin with a <mergeTarget> configured. It is therefore quite typical for devs to check in temporary branches that git then merges to the <mergeTarget> branch and pushes back to the central repo. As it is now this means that jenkins doesn't send emails in the case of a build failure for such new branches. I've noticed in the console output from builds on new branches that the git-plugin writes No change to record in branch XXX This is written by the git-plugin if it cannot find a previous build. In the case where a job is configured with a mergeTarget I believe that the right solution is either 1. always use <mergeRemote>/<mergeTarget> as the previous ref or 2. Look for a previous build for the branch first and then fall back to <mergeRemote>/<mergeTarget> The names <mergeRemote> and <mergeTarget> are from the config.xml file, where I for example have: <userMergeOptions> <mergeRemote>origin</mergeRemote> <mergeTarget>release/5.0.0</mergeTarget> </userMergeOptions>

          tsondergaard added a comment -

          Patch to make git plugin compute changelog differently for jobs configured with a merge-target

          tsondergaard added a comment - Patch to make git plugin compute changelog differently for jobs configured with a merge-target
          tsondergaard made changes -
          Attachment New: git-plugin.diff [ 22201 ]

            Unassigned Unassigned
            jpschewe jpschewe
            Votes:
            19 Vote for this issue
            Watchers:
            25 Start watching this issue

              Created:
              Updated: