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

First time build does not show changelog

    XMLWordPrintable

    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
          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.
          Hide
          mkroell Michael Kroell added a comment -

          Hello, I am experiencing these issues as well using Bitbucket with a Multibranch Pipeline. This is causing issues with using other plugins looking to use the changelog, specifically the Atlassian Jira Cloud plugin.  Here is some logs on the issue:

          [Pipeline] {
          [Pipeline] stage
          [Pipeline]

          { (Declarative: Checkout SCM) [Pipeline] checkout The recommended git tool is: NONE using credential Jenkins-Bitbucket-Build-Status-Notifier Fetching changes from the remote Git repository Fetching without tags > git rev-parse --is-inside-work-tree # timeout=10 > git config remote.origin.url https://x-token-auth##@bitbucket.org/##/jenkins-experimental.git # timeout=10 Fetching upstream changes from https://x-token-auth@bitbucket.org/##/jenkins-experimental.git > git --version # timeout=10 > git --version # 'git version 2.20.1' > git fetch --no-tags --force --progress -- https://x-token-auth:##@bitbucket.org/##/jenkins-experimental.git +refs/heads/CDE-888-Jira-Test:refs/remotes/origin/CDE-888-Jira-Test # timeout=10 Checking out Revision a40df9adb4445594d996cb282389acd8c629be8e (CDE-888-Jira-Test) Commit message: "CDE-888" *First time build. Skipping changelog.* [Checks API] No suitable checks publisher found. [Pipeline] }

          [Pipeline] // stage
          [Pipeline] withEnv
          [Pipeline] {
          > git config core.sparsecheckout # timeout=10
          > git checkout -f a40df9adb4445594d996cb282389acd8c629be8e # timeout=10
          [Pipeline] stage
          [Pipeline] { (Test Build)

           

          This is the fourth build on a pull request, which is bizzard this is showing as "First Time Build." This causes errors downstream to other plugins:

          [Pipeline] jiraSendDeploymentInfo

          jiraSendDeploymentInfo: SKIPPED_ISSUE_KEYS_NOT_FOUND_AND_SERVICE_IDS_ARE_EMPTY: No issue keys found in the change log and service ids were not provided. Not sending deployment information to Jira: godeepseltzer.atlassian.net.

           

           

          Show
          mkroell Michael Kroell added a comment - Hello, I am experiencing these issues as well using Bitbucket with a Multibranch Pipeline. This is causing issues with using other plugins looking to use the changelog, specifically the Atlassian Jira Cloud plugin.  Here is some logs on the issue: [Pipeline] { [Pipeline] stage [Pipeline] { (Declarative: Checkout SCM) [Pipeline] checkout The recommended git tool is: NONE using credential Jenkins-Bitbucket-Build-Status-Notifier Fetching changes from the remote Git repository Fetching without tags > git rev-parse --is-inside-work-tree # timeout=10 > git config remote.origin.url https://x-token-auth##@bitbucket.org/##/jenkins-experimental.git # timeout=10 Fetching upstream changes from https://x-token-auth@bitbucket.org/##/jenkins-experimental.git > git --version # timeout=10 > git --version # 'git version 2.20.1' > git fetch --no-tags --force --progress -- https://x-token-auth:##@bitbucket.org/##/jenkins-experimental.git +refs/heads/CDE-888-Jira-Test:refs/remotes/origin/CDE-888-Jira-Test # timeout=10 Checking out Revision a40df9adb4445594d996cb282389acd8c629be8e (CDE-888-Jira-Test) Commit message: "CDE-888" *First time build. Skipping changelog.* [Checks API] No suitable checks publisher found. [Pipeline] } [Pipeline] // stage [Pipeline] withEnv [Pipeline] { > git config core.sparsecheckout # timeout=10 > git checkout -f a40df9adb4445594d996cb282389acd8c629be8e # timeout=10 [Pipeline] stage [Pipeline] { (Test Build)   This is the fourth build on a pull request, which is bizzard this is showing as "First Time Build." This causes errors downstream to other plugins: [Pipeline] jiraSendDeploymentInfo jiraSendDeploymentInfo: SKIPPED_ISSUE_KEYS_NOT_FOUND_AND_SERVICE_IDS_ARE_EMPTY: No issue keys found in the change log and service ids were not provided. Not sending deployment information to Jira: godeepseltzer.atlassian.net.    
          Hide
          markewaite Mark Waite added a comment -

          Michael Kroell you're describing a very different case than is described by the other comments in this issue. This issue describes that the user would like the git plugin to provide a reliable guess of the commits that compose the first commit in a branch. That causes the first build on a branch to show no changes.

          I think the problem you're describing is that a non-initial build has changes but is not correctly calculating those changes.

          Show
          markewaite Mark Waite added a comment - Michael Kroell you're describing a very different case than is described by the other comments in this issue. This issue describes that the user would like the git plugin to provide a reliable guess of the commits that compose the first commit in a branch. That causes the first build on a branch to show no changes. I think the problem you're describing is that a non-initial build has changes but is not correctly calculating those changes.

            People

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

              Dates

              Created:
              Updated:
              Resolved: