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

Multi branch with same commit not getting triggered as expected

XMLWordPrintable

      Hi Team,
      I have gate job which will trigger a another child build job if the branch has a different commit in that day.

      EX:
      Let B1,B2 and B3 as Branches
      Let C1,C2 and C3 as commits

      B1 has C1
      B2 has commits C1 and C2
      B3 has C3

      I have added all my branch details in "Branches to build"
      When build the gate job, B2 and B3 are getting build in child job.

      I am using version "2.3.5" of GIT plugin. Git plugin is Comparing the Branches commit points and it is omitting the branch commit if it has already in other branch.

      So child job is not getting triggered for that branch.

      Thanks in Advance,

          [JENKINS-38866] Multi branch with same commit not getting triggered as expected

          Arun Kumar S K created issue -
          Mark Waite made changes -
          Assignee Original: Mark Waite [ markewaite ]

          Mark Waite added a comment -

          Git plugin 2.3.5 was released over 18 months ago, Feb 2015. Does the same problem appear in a current release of the git plugin and the git client plugin?

          Can you provide step by step instructions (or even better one or more jobs submitted to the bugs folder of my docker instance)?

          Mark Waite added a comment - Git plugin 2.3.5 was released over 18 months ago, Feb 2015. Does the same problem appear in a current release of the git plugin and the git client plugin? Can you provide step by step instructions (or even better one or more jobs submitted to the bugs folder of my docker instance )?

          Arun Kumar S K added a comment -

          Hi markewaite
          Due to Jenkins version restrictions I am using the world Git plugin.

          Below are steps to reproduce the scenario.
          1. Create a branch in Git as "Branch1"
          2. Add some dummy project to build in "Branch1"
          3. Clone the branch from "Branch1" into "Branch2" (Now Both the branch will be in same commit point)
          4. Create a new Jenkins job with both branch details in "Branches to build".
          5. When hitting "Build now", build need to triggered for both the builds sequentially(but it is not happening. It triggers only 1st branch not the other).

          Cheers,
          AK

          Arun Kumar S K added a comment - Hi markewaite Due to Jenkins version restrictions I am using the world Git plugin. Below are steps to reproduce the scenario. 1. Create a branch in Git as "Branch1" 2. Add some dummy project to build in "Branch1" 3. Clone the branch from "Branch1" into "Branch2" (Now Both the branch will be in same commit point) 4. Create a new Jenkins job with both branch details in "Branches to build". 5. When hitting "Build now", build need to triggered for both the builds sequentially(but it is not happening. It triggers only 1st branch not the other). Cheers, AK

          Mark Waite added a comment -

          arunk78 you are describing a different case than the original bug report. You are asking for the same commit (SHA1) to be built twice because it is referenced by two different branches. That's not how the git plugin perceives a repository. The git plugin considers that once a commit (SHA1) has been built, it should generally not build it again. The name of the branch pointing to that commit (SHA1) is not included in the decision if a commit should be built or not.

          Mark Waite added a comment - arunk78 you are describing a different case than the original bug report. You are asking for the same commit (SHA1) to be built twice because it is referenced by two different branches. That's not how the git plugin perceives a repository. The git plugin considers that once a commit (SHA1) has been built, it should generally not build it again. The name of the branch pointing to that commit (SHA1) is not included in the decision if a commit should be built or not.

          Arun Kumar S K added a comment -

          markewaite

          There is another scenario also.

          Steps are same as previous comment.
          1. Branch1 has commit C1
          2. Branch2 has commit C1+C2 (it means it has code of branch1 + new code)

          At this time also It triggers only one branch not the other

          Cheers,
          AK

          Arun Kumar S K added a comment - markewaite There is another scenario also. Steps are same as previous comment. 1. Branch1 has commit C1 2. Branch2 has commit C1+C2 (it means it has code of branch1 + new code) At this time also It triggers only one branch not the other Cheers, AK
          Arun Kumar S K made changes -
          Assignee New: Mark Waite [ markewaite ]
          Mark Waite made changes -
          Assignee Original: Mark Waite [ markewaite ]

          Arun Kumar S K added a comment -

          Hi markewaite,
          Can you suggest for the above scenario??

          Cheers,
          AK

          Arun Kumar S K added a comment - Hi markewaite , Can you suggest for the above scenario?? Cheers, AK

          Mark Waite added a comment -

          As far as I can tell, that is a similar scenario as was described earlier.

          First branch is a subset of second branch. If the superset branch has been built, then the subset branch is assumed to also have been included in that superset.

          You could implement an alternative build chooser (refer to the Git Chooser Alternative Plugin for an example) that would choose by different rules than the current implementation.

          You could add an empty commit on the subset branch so that it is no longer a subset.

          Mark Waite added a comment - As far as I can tell, that is a similar scenario as was described earlier. First branch is a subset of second branch. If the superset branch has been built, then the subset branch is assumed to also have been included in that superset. You could implement an alternative build chooser (refer to the Git Chooser Alternative Plugin for an example) that would choose by different rules than the current implementation. You could add an empty commit on the subset branch so that it is no longer a subset.

            Unassigned Unassigned
            arunk78 Arun Kumar S K
            Votes:
            2 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: