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

Use the forensics API to create the changeset

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • git-plugin
    • None

      I'm not sure how the changeset is created by the git plugin. I see in https://plugins.jenkins.io/git/#changelog-extensions that I can ask it to compare against a specific branch. But this raises the question of what happens when I have

      * master
      |
      | * my_branch
      |/
      * old_master
      |

      and I compare my_branch with master. I don't know the answer.

      It seems to me the git plugin could benefit from using the "Reference build" from the https://plugins.jenkins.io/forensics-api/.

       

      Additionally, when creating a multibranch pipeline with a GitHub branch source I can't really see the "Calculate changelog against a specific branch" option anywhere, I don't think it's available.

       

      The current behaviour makes, for example, the first commit of a new branch lack any changeset at all.

       

          [JENKINS-66893] Use the forensics API to create the changeset

          I don’t think the reference build is the right thing to use here. IIRC it defaults to the last build of the target branch that does not have any commits that are not also on the source branch. If a later build of the target branch does have such commits, then it won’t be the reference build, but calculating the changelog against it is still OK. If you calculate the changelog against the reference build, then the changelog can include commits that are on the source branch and also on a later build of the target branch. It would be better to omit those commits from the changelog.

          Kalle Niemitalo added a comment - I don’t think the reference build is the right thing to use here. IIRC it defaults to the last build of the target branch that does not have any commits that are not also on the source branch. If a later build of the target branch does have such commits, then it won’t be the reference build, but calculating the changelog against it is still OK. If you calculate the changelog against the reference build, then the changelog can include commits that are on the source branch and also on a later build of the target branch. It would be better to omit those commits from the changelog.

          Also, forensics-api-plugin has quite a lot of dependencies, even on JavaScript plugins; perhaps not the best practice for an API plugin.

          Kalle Niemitalo added a comment - Also, forensics-api-plugin has quite a lot of dependencies, even on JavaScript plugins; perhaps not the best practice for an API plugin.

          Mark Waite added a comment -

          I think that the fallible rules that can be used to choose the comparison commit for a new branch with command line git are too widely varied to be practical. Should the comparison be at the most recent commit pointed to by more than one predecessor commits? Should the comparison be at the most recent commit ("branch starting point") that is shared with a user designated base branch? Should the comparison be at the most recent commit ("tip") on a designated base branch? What happens when a single repository has multiple lines of development running concurrently? The questions are varied enough that I think they need to be answered by the git hosting provider using the pull request or merge request concept from the hosting provider.

          GitHub, GitLab, Bitbucket, and other SCM provider API's to determine the destination branch for a pull request or merge request. I think that if we want a changeset for the first commit of a new multibranch Pipeline job, then we want to ask the SCM provider to report the destination of the pull request so that the changeset can be computed based on the pull request merge destination.

          Might be an interesting Google Summer of Code project if someone would like to draft a proposal.

          Mark Waite added a comment - I think that the fallible rules that can be used to choose the comparison commit for a new branch with command line git are too widely varied to be practical. Should the comparison be at the most recent commit pointed to by more than one predecessor commits? Should the comparison be at the most recent commit ("branch starting point") that is shared with a user designated base branch? Should the comparison be at the most recent commit ("tip") on a designated base branch? What happens when a single repository has multiple lines of development running concurrently? The questions are varied enough that I think they need to be answered by the git hosting provider using the pull request or merge request concept from the hosting provider. GitHub, GitLab, Bitbucket, and other SCM provider API's to determine the destination branch for a pull request or merge request. I think that if we want a changeset for the first commit of a new multibranch Pipeline job, then we want to ask the SCM provider to report the destination of the pull request so that the changeset can be computed based on the pull request merge destination. Might be an interesting Google Summer of Code project if someone would like to draft a proposal.

          Altering the changelog generation algorithm might require modifying the SCM Skip plugin as well.

          Kalle Niemitalo added a comment - Altering the changelog generation algorithm might require modifying the SCM Skip plugin as well.

            Unassigned Unassigned
            reddwarf94 Cristian
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: