I can't duplicate the bug based on the steps you've provided. Can you provide more details or clarify the areas in which my steps are different than your steps?

Steps I took:

1. Create a new git repo ( repo=~/git/bugs/JENKINS-26534; mkdir -p $repo; cd $repo; git init )
2. Commit a change to that repo ( branch=master; date >> $branch; git add $branch; git commit -m "Add date to $branch" )
3. Create a freestyle project to monitor that repo ( poll git often, or create a post-receive hook )
4. Define "Branches to build" as "*" so that any branch which appears will start a build
5. Confirm that the project builds on its first polling interval
6. Confirm that the log of the first build contains the line "First time build. Skipping changelog."
7. Confirm that Changes and Recent Changes show no change for that first time build
8. Add a branch to the repo with a commit ( branch=branch-a; git checkout -b $branch; date >> $branch; git add $branch; git commit -m "Add date to $branch" )
9. Confirm that the next poll starts that job
10. Confirm that the console output contains the line "First time build. Skipping changelog."
11. Commit a second change to the branch (branch=branch-a; git checkout $branch; date >> $branch; git add $branch; git commit -m "Add date to $branch" )
12. Confirm that the next poll starts that job
13. Confirm that the changes show the commit (since it is not a first time build)

Is the bug you're reporting that the first time build for a new branch does not list any changes? If so, it is difficult to make a good general case decision of what should be the basis of those changes.

I confirmed that a multi-branch job (recently added plugin which allows a git or subversion based job to create a new job for each new branch detected) behaves similarly. The first build of a new job lists in the console output that it is a first time build and is not computing the changelog. Subsequent builds compute the changelog.

Yes, the problem related to the first time build for new branch, which was discovered by Git polling. For the next changes in existing remote branch changes are shown correct.
I don't know details of the implementation of Git plugin, but it seems to me, that plugin can store list of all commit hashes of repository and when it see new remote branch, try to find those commits which are in new branch but not in commits store.
And then build changelog based on these commits.

There isn't any way to reliably decide which branch should be the basis for the diff calculation you're proposing for an initial branch. There may be many different heuristics (fallible rules) which could be applied to the case, but there will be cases where each of the heuristics is wrong.

This happens for us too. The git plugin reports the correct commit hash of the changeset but it shows No Changes on the Changes view.

What is the fix? Thanks.

benja1, as far as I can tell from this bug report, it wants that the first commit on a newly created branch should show changes from something, but "something" can't be reliably determined. Are you requesting that the first build on a new branch should show changes from the branch that was used as the basis for the new branch?

There is an "Additional Behaviour" which will allow all change reports to be based on a specific branch. If your workflow is creating branches from a specific, single base branch, you could list that base branch as the base to compute changes.

There isn't a general way to decide which branch is the "origin" for the current commit, since it is a directed graph from the current commit to its predecessors. There could be many different branches in that directed graph, and the "real" base branch could have advanced since the branch point. I'm quite hesitant to place a "parent guesser" into the plugin, since that will result in some set of users being frustrated that it did not guess their case.

The bug was resolved as "Won't fix"...

Exactly. We perform a first commit(s) and push of a new branch. The Jenkins job is set to build any branch in the repository with the "**" branch specifier.

To verify, is this a problem with the git plugin? Is the issue tracked anywhere else? This feature is important to our workflow.

It is tracked here, and has been decided that it won't be fixed.

It is how the git plugin is defined to behave. Unless the "base branch to compute changes" is set, the first build does not attempt to compute a difference with any predecessor, because there is no predecessor for the first build on a branch.

Is there a way to work around this issue? We also do not want our Jenkins job to build on branch creation when the branch is first pushed to the remote repository. We are only creating local branches and then pushing them once the feature is complete because otherwise the Jenkins job is triggered upon branch creation with no commits yet.

You might push a "dummy commit" as the first commit on a new branch so that Jenkins will detect the new branch and see that it is not the same SHA1 as has already been built, then future changes after that "dummy commit" will show as differences in the Jenkins job.

markewaite you told that there is some "Additional Behaviour which will allow all change reports to be based on a specific branch". Could you please tell me which exactly Additional Behaviour could do that.

I am using Git Plugin v.3.6.4, and all behaviour that i have are shown on picture.

Thx.

pajok the option is not available for multi-branch pipelines.  The first build of a multi-branch pipeline happens when the branch is discovered.  Multi-branch pipeline checkout has intentionally simplified the available options to those needed by most users.

I suspect you could create a plugin which adds that option.  That has the benefit that typical users don't see the option unless they choose to install the plugin.

Hi!

Sorry to resurrect this old issue, but we faced same issue and need some way to solve it. We use multibranch pipeline with scripted Jenkinsfile which should run some stages based on changes we have in a github PR. For this reason we use currentBuild.changeSets and continue collecting changes up to first commit in a branch (until build.previousBuild is null, in a while loop). But this strange issue was discovered and I wonder what are the options to solve this nowadays?

Seems like we still don't have a "hidden" option to define parent branch, but I wonder why it is a problem actually. Github solves this somehow in their "commits" Tab. Doesn't any GIT commit point to it's parent commit? Cannot we compare using this info?

Thanks!

olegstepura Pull request 637 includes a proposal to provide a changelog for the first build of a branch. It is currently in the "Later" milestone because it is not receiving my focused evaluation right now. After git plugin 4.0 has stabilized and released, I'll evaluate the pull requests in the "Later" milestone to decide which should be reopened and be reviewed.

I'd love to have your help evaluating the changes that are proposed in that pull request. You'd need to build a local copy of the plugin based on that pull request, use it in your environment, and report the results to the pull request.

If you're not comfortable building the pull request, I could temporarily reopen the request, have the CI servers build it, then point you to the built artifact so that you could test it.

See JENKINS-14138 and that pull request for more details

Hi!

Thanks for quick reply and sorry I did not react as fast. I discussed internally if this is acceptable to do what you suggested and it was not, but another option to workaround the limitations here was found: JENKINS-54285

I tried using commands from that ticket, it works if we use big enough shallow clone depth (I set it to 100).

the only issue I faced was being unable to use sh in a function. It looks buggy. Seems like I cannot simply define a function like this:

def getLastCommitHash() {
  return sh(
    returnStdout: true,
    script: "git show -s --no-abbrev-commit --pretty=format:%P%n%H%n HEAD"
  ).trim().split("\n").last().trim()
}

and the use it: 

def otherFunction() {
  def lastCommit = getLastCommitHash()
  // do something else with it expecting lastCommit has one-line string
  return [a, b, c]
}

In the example above otherFunction() will return exact unprocessed output of sh command from getLastCommitHash() function. This is weird.

I was able to workaround this creating simple functions which only run sh commands and do no post-processing (just return sh output) and other functions that only work with strings and not do anything with sh. Then all those functions are used together inside our main node {} context.

def getHeads() {
  return sh(
    returnStdout: true,
    script: "git show -s --no-abbrev-commit --pretty=format:%P%n%H%n HEAD"
  )
}

def getLastCommitHash(headsOutput) {
  return headsOutput.trim().split("\n").last().trim()
}

 then use this in Jenkinsfile:

node("xxx") {
  def headsOutput = getHeads()
  def lastCommitHash = getLastCommitHash(headsOutput)
  // ...
}

Is that really resolved?

The problem is really serious  we can't use 'changeset' in when condition with branches at all.

It is resolved as "Won't Fix". Refer to the earlier discussions for more details.

There is this pull request that attempts to apply heuristics to decide which change should be used as the basis for a changeset. You're welcome to propose further changes to it to resolve the issues that are discussed in it.

markewaite what are your thoughts on having `changeset` support a remote ref variable with a default being an empty string, that way a user can specify the base remote ref and that can be used to help the plugin decide how to compute the changeset/changelog. The default variable ensures the code is backwards compatible so folks who don't explicitly supply a remote ref gets their old behavior. I have not dug into the code so I don't know if my suggestion is at all realistic.

bjhaid the plugin has the concept of a base branch for comparison. Users that are willing to use the base branch to compute the changelog might be able to see changelogs on the first commit, though that changelog will be incorrect if their actual base branch does not match the base branch used to compute the changelog.

As an example, there are two development branches for a GitHub repo, one named 'master' and one named 'stable-3.x'. 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.

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.

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

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

It uses the commit hash.

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.

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

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]

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

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