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

First time build does not show changelog

    Details

    • Similar Issues:

      Description

      Suppose, we have master branch. Then we checkout to a new branch, lets name it branch1:

      git checkout -b branch1
      

      Then we do some commits:

      echo "a" > a.txt && git add a.txt && git commit -m 'Added file: a.txt'
      echo "b" > b.txt && git add b.txt && git commit -m 'Added file: b.txt'
      

      Then we push our branch to Git repository:

      git push origin branch1
      

      In Jenkins, Git polling reports:

      ...
      Seen branch in repository origin/branch1
      Seen XXX remote branches
       > /usr/bin/git log --full-history --no-abbrev --format=raw -M -m --raw 0a6eb107fea5bb6371c450db1b5f6e100e0fba28..d8c5018ca184fb75e46386de2f16e552906fe106 # timeout=10
      Done. Took 3.5 sec
      Changes found
      

      but Changes section shows nothing, it means, that no changes were made. Nevertheless, build was triggered.

      The problem is deeper, suppose our build runs unit tests, and they failed. In that case, no emails will be send to committers, because of no changes. We have caught this case and got a problems
      I think, it's a bug, because 2 new commits were created and Jenkins should show it in Changes section.

        Attachments

          Activity

          Hide
          bjhaid Ayodele Abejide added a comment -

          Thanks for the response!

          > If the Jenkinsfile declares the changelog should be computed against the 'master' branch, then all pull requests to the 'stable-3.x' branch will incorrectly compute their changelog against the 'master' branch.

          I understand this concern, do you think documentation should be adequate in covering this concern? Also what are your thoughts on refinement of my suggestion below:

          A user can provide a fall through base branch when the plugin cannot correctly compute the changelog (i.e on the first commit on a branch), obviously shares similar risks as the original proposal, but in this case it risk is much less, and will still need documentation on the risks.

          Show
          bjhaid Ayodele Abejide added a comment - Thanks for the response! > If the Jenkinsfile declares the changelog should be computed against the 'master' branch, then all pull requests to the 'stable-3.x' branch will incorrectly compute their changelog against the 'master' branch. I understand this concern, do you think documentation should be adequate in covering this concern? Also what are your thoughts on refinement of my suggestion below: A user can provide a fall through base branch when the plugin cannot correctly compute the changelog (i.e on the first commit on a branch), obviously shares similar risks as the original proposal, but in this case it risk is much less, and will still need documentation on the risks.
          Hide
          djviking Sverre Moe added a comment - - edited

          This issue has also been experienced on branches that had been rebased.
          If you rebase N-commits, for which thos commits was a part of the last builds changeset, then it will treat the new build as a first time build.

          Using ChangelogToBranch could work, but it will add additional boilerplate code to our pipeline, instead of just calling checkout scm.
          For use it is useless to configure it for the job, because we do not know the base branch (compareTarget) until the job has started.

          Does the git plugin check for changes using the git commit hash or message?

          If it detects "first time build", then it should use the latest commit as changeset.
          Build #1
          > Commit message: "fix: Correct this method"
          > First time build. Skipping changelog

          Rebase commit, new hash, same message.
          Build #2
          > Commit message: "fix: Correct this method"
          > First time build. Skipping changelog

          Show
          djviking Sverre Moe added a comment - - edited This issue has also been experienced on branches that had been rebased. If you rebase N-commits, for which thos commits was a part of the last builds changeset, then it will treat the new build as a first time build. Using ChangelogToBranch could work, but it will add additional boilerplate code to our pipeline, instead of just calling checkout scm. For use it is useless to configure it for the job, because we do not know the base branch (compareTarget) until the job has started. Does the git plugin check for changes using the git commit hash or message? If it detects "first time build", then it should use the latest commit as changeset. Build #1 > Commit message: "fix: Correct this method" > First time build. Skipping changelog Rebase commit, new hash, same message. Build #2 > Commit message: "fix: Correct this method" > First time build. Skipping changelog
          Hide
          markewaite Mark Waite added a comment - - edited

          Does the git plugin check for changes using the git commit hash or message?

          It uses the commit hash.

          Show
          markewaite Mark Waite added a comment - - edited Does the git plugin check for changes using the git commit hash or message? It uses the commit hash.
          Hide
          djviking Sverre Moe added a comment -

          Is it a bug then, when a rebase there are no changes? It is a changed commit and new hash, but it treats it as First time build thus no changes.

          Show
          djviking Sverre Moe added a comment - Is it a bug then, when a rebase there are no changes? It is a changed commit and new hash, but it treats it as First time build thus no changes.
          Hide
          markewaite Mark Waite added a comment - - edited

          Sverre Moe I like the definition of "bug" that Gerald Weinberg and Cem Kaner offered. It's a "bug" if it "bugs someone". In the case you're describing, a bug report would be a good way to start the discussions of what you would expect as a user in the case of a rebase.

          I believe the current process compares the preceding build to the current build. If there is no path from the preceding build to current build (as would often happen in a rebase), then no changes are displayed.

          If you decide to open that issue, please describe what you would like to happen as a user, paying particular attention to the cases where you're assuming that the git plugin knows the base branch from which the pull request started. It doesn't actually know a base branch unless specifically told to show differences against a base branch. Heuristics to guess the base branch are prone to fail in all sorts of unfriendly ways.

          Show
          markewaite Mark Waite added a comment - - edited Sverre Moe I like the definition of "bug" that Gerald Weinberg and Cem Kaner offered. It's a "bug" if it "bugs someone". In the case you're describing, a bug report would be a good way to start the discussions of what you would expect as a user in the case of a rebase. I believe the current process compares the preceding build to the current build. If there is no path from the preceding build to current build (as would often happen in a rebase), then no changes are displayed. If you decide to open that issue, please describe what you would like to happen as a user, paying particular attention to the cases where you're assuming that the git plugin knows the base branch from which the pull request started. It doesn't actually know a base branch unless specifically told to show differences against a base branch. Heuristics to guess the base branch are prone to fail in all sorts of unfriendly ways.

            People

            • Assignee:
              ndeloof Nicolas De Loof
              Reporter:
              maxusachev Max Usachev
            • Votes:
              0 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: