[JIRA] (JENKINS-26354) First time build does not show changelog

176 views
Skip to first unread message

oleg@stepura.com (JIRA)

unread,
Apr 8, 2019, 9:37:04 AM4/8/19
to jenkinsc...@googlegroups.com
Oleg Stepura commented on Bug JENKINS-26354
 
Re: First time build does not show changelog

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!

Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

mark.earl.waite@gmail.com (JIRA)

unread,
Apr 8, 2019, 10:01:03 AM4/8/19
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-26354
[~olegstepura] [Pull request 637|https://github.com/jenkinsci/git-plugin/pull/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

mark.earl.waite@gmail.com (JIRA)

unread,
Apr 8, 2019, 10:01:05 AM4/8/19
to jenkinsc...@googlegroups.com

Oleg Stepura 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.

oleg@stepura.com (JIRA)

unread,
Apr 9, 2019, 12:27:02 PM4/9/19
to jenkinsc...@googlegroups.com

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)
  // ...
}

 

tamerlaha@gmail.com (JIRA)

unread,
Aug 9, 2019, 3:32:02 PM8/9/19
to jenkinsc...@googlegroups.com
ipleten commented on Bug JENKINS-26354

Is that really resolved?

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

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 9, 2019, 8:33:03 PM8/9/19
to jenkinsc...@googlegroups.com

It is resolved as "Won't Fix".

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.

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 9, 2019, 8:35:03 PM8/9/19
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-26354
It is resolved as "Won't Fix".   
  Refer to [the earlier discussions|https://issues.jenkins-ci.org/browse/JENKINS-26354?focusedCommentId=364445&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-364445] for more details.

There is [this pull request|https://github.com/jenkinsci/git-plugin/pull/637] 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.

alex@firefly.ai (JIRA)

unread,
Aug 12, 2019, 9:19:04 AM8/12/19
to jenkinsc...@googlegroups.com

I was able to get the changeset using the following:

checkout scm: [
    $class: 'GitSCM',
    branches: [[name: env.BRANCH_NAME]],
    extensions: [
        [
            $class: 'ChangelogToBranch',
            options: [
                compareRemote: 'origin',
                compareTarget: 'master'
            ]
        ]
    ],
    userRemoteConfigs: [
        [
            url: scm.getUserRemoteConfigs()[0].getUrl(),
            refspec: scm.getUserRemoteConfigs()[0].getRefspec(),
            credentialsId: 'github-privatekey'
        ]
    ]
]

With the above I can get a changeset from the first build.

 

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 22, 2019, 9:32:00 PM10/22/19
to jenkinsc...@googlegroups.com
Mark Waite closed an issue as Won't Fix
 
Jenkins / Bug JENKINS-26354
Change By: Mark Waite
Status: Resolved Closed
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo

abejideayodele@gmail.com (JIRA)

unread,
Feb 5, 2020, 12:16:03 PM2/5/20
to jenkinsc...@googlegroups.com
Ayodele Abejide commented on Bug JENKINS-26354
 
Re: First time build does not show changelog

Mark Waite 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.

mark.earl.waite@gmail.com (JIRA)

unread,
Feb 5, 2020, 4:01:03 PM2/5/20
to jenkinsc...@googlegroups.com

Ayodele Abejide 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.

abejideayodele@gmail.com (JIRA)

unread,
Feb 5, 2020, 4:24:06 PM2/5/20
to jenkinsc...@googlegroups.com

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.

sverre.moe@gmail.com (JIRA)

unread,
May 4, 2020, 7:10:04 AM5/4/20
to jenkinsc...@googlegroups.com

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.

This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
Atlassian logo

sverre.moe@gmail.com (JIRA)

unread,
May 4, 2020, 8:39:03 AM5/4/20
to jenkinsc...@googlegroups.com
Sverre Moe edited a comment on Bug JENKINS-26354
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

mark.earl.waite@gmail.com (JIRA)

unread,
May 4, 2020, 10:52:04 AM5/4/20
to jenkinsc...@googlegroups.com

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

It uses the commit hash.

mark.earl.waite@gmail.com (JIRA)

unread,
May 4, 2020, 10:53:03 AM5/4/20
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-26354
> bq. Does the git plugin check for changes using the git commit hash or message?


It uses the commit hash.
Reply all
Reply to author
Forward
0 new messages