• 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 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.

          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

          jpschewe added a comment -

          Will this create a changeset for new branches even if I don't have Jenkins setup to do merges itself?

          jpschewe added a comment - Will this create a changeset for new branches even if I don't have Jenkins setup to do merges itself?

          tsondergaard added a comment -

          No, the patch only changes the behavior for the case where there is a merge target. The merge target branch is a reasonable reference for new (not built before) branches - Without it what would you consider a reasonable reference? From your comment 9/Jun/12 12:03 it is clear that you would want the changeset to be relative to 'master', but 'master' is just another branch to git. How should it know that you want change sets to be computed relative to 'master'?

          A change that could serve both of us would be to add a configuration option to the git plugin where you can specify that you want changesets to be computed relative to a named branch, ie you would have to check a box "Compute changesets relative to named branch" and fill in the name of the branch. That would work for both of us.

          tsondergaard added a comment - No, the patch only changes the behavior for the case where there is a merge target. The merge target branch is a reasonable reference for new (not built before) branches - Without it what would you consider a reasonable reference? From your comment 9/Jun/12 12:03 it is clear that you would want the changeset to be relative to 'master', but 'master' is just another branch to git. How should it know that you want change sets to be computed relative to 'master'? A change that could serve both of us would be to add a configuration option to the git plugin where you can specify that you want changesets to be computed relative to a named branch, ie you would have to check a box "Compute changesets relative to named branch" and fill in the name of the branch. That would work for both of us.

          jpschewe added a comment -

          Am I correct in assuming that the git plugin tracks the last commit that was built for each branch? So you build the list of changes for a given branch by talking the tree of all commits on that branch since the last build. Correct?

          If you have this information, then you can get the list of commits for this new branch and walk backwards until you run into a commit that has already been built. That list of commits is the change set for the new branch.
          Something like this:

          {{

          List<String> changeset = new LinkedList<String>();
          String currentCommit = new branch HEAD
          boolean done = false;
          while(!done) {
          for(String builtCommit : latestCommit for each known branch) {
          if(history(buildCommit).contains(currentCommit))

          { done = true; }


          }
          if(!done)

          { changeset.add(currentCommit); }

          }

          }}

          jpschewe added a comment - Am I correct in assuming that the git plugin tracks the last commit that was built for each branch? So you build the list of changes for a given branch by talking the tree of all commits on that branch since the last build. Correct? If you have this information, then you can get the list of commits for this new branch and walk backwards until you run into a commit that has already been built. That list of commits is the change set for the new branch. Something like this: {{ List<String> changeset = new LinkedList<String>(); String currentCommit = new branch HEAD boolean done = false; while(!done) { for(String builtCommit : latestCommit for each known branch) { if(history(buildCommit).contains(currentCommit)) { done = true; } } if(!done) { changeset.add(currentCommit); } } }}

          nhnb added a comment -

          Jenkin's git ability to accept feature branches, process them, and merge them to master, if test pass, is really great.

          Using the target branch as baseline, seems like a good approach. Although it does not fix all situations, it will enable that workflow without losing the change list, which is quite a major feature.

          nhnb added a comment - Jenkin's git ability to accept feature branches, process them, and merge them to master, if test pass, is really great. Using the target branch as baseline, seems like a good approach. Although it does not fix all situations, it will enable that workflow without losing the change list, which is quite a major feature.

          tsondergaard added a comment -

          @nhnb:

          The change to use the merge target as baseline for computing the changelog has been accepted (commit 5ae255594bd7e118bee6c58eae504d1c49e9f97b). As far as I'm concerned this bug can be resolved now, but I
          don't think the OP is satisfied.

          tsondergaard added a comment - @nhnb: The change to use the merge target as baseline for computing the changelog has been accepted (commit 5ae255594bd7e118bee6c58eae504d1c49e9f97b). As far as I'm concerned this bug can be resolved now, but I don't think the OP is satisfied.

          jpschewe added a comment -

          If this only works when Jenkins is setup to do merges, then I know I'm not satisfied and I suspect the OP isn't either. We really need to be able to provide feedback to the committers when they push a new branch and we really don't want to spam everyone on the project with email about branches that they're not working on.

          jpschewe added a comment - If this only works when Jenkins is setup to do merges, then I know I'm not satisfied and I suspect the OP isn't either. We really need to be able to provide feedback to the committers when they push a new branch and we really don't want to spam everyone on the project with email about branches that they're not working on.

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

              Created:
              Updated: