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

Cannot reference git remotes in branch discovery

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • git-plugin
    • Jenkins 2.88
      Git Plugin 3.6.4

      We have "aggregate" repositories which pool a number of remotes into a single repo, allowing them to be tested with a single Jenkins job.

      eg.
      development ../../development/project.git
      upstream ../../mirror/project.git
      personal ../../personal/project.git

      Using the patches from Jenkins 33445, these appear in Jenkins as <remote>/<branch>

       eg.
      development/master
      development/feature
      upstream/master
      upstream/release-1
      personal/feature

       We are trying to migrate away from the non-upstreamed code in Jenkins 33445, but cannot access the referenced repos via the aggregate repository. To do this, I have tried specifying the custom refspec

      +refs/remotes/*:refs/remotes/*

      > git ls-remote -h -t git://gitlab.ozlabs.ibm.com/aggregate/skiboot.git # timeout=30
      Checking branches...
      Processed 0 branches

      First up, the '-h' switch restricts the list to only

      'refs/heads/*'

      , while the branches we care about are in

      'refs/remotes/*'

      . Removing these switches (by setting the args to getRemoteReferences()) get us a little further, but it still shows "Processed 0 branches".

      Digging a bit further, it looks like we make the assumption that a branch is prefixed with Constants.R_HEADS in a number of places. We may be better off storing the path as well as the name in SCMHead instead, and not trying to construct path.

      We have a partial workaround in that we can specify multiple branch sources, but we do lose the repo prefix, so development/feature and personal/feature collide as 'feature'.

       

          [JENKINS-47854] Cannot reference git remotes in branch discovery

          Mark Waite added a comment -

          I think that your use case is unique enough (combining multiple repositories into a single repository at the git repo, rather than in the Jenkins job), that you'll need to plan to use the git plugin API's traits facilities to create a custom plugin which supports your use case.

          stephenc provided some good guidance for others as they have started creating the tag discovery plugin(s). I've referenced him on this comment in case he can point you to those same suggestions.

          Mark Waite added a comment - I think that your use case is unique enough (combining multiple repositories into a single repository at the git repo, rather than in the Jenkins job), that you'll need to plan to use the git plugin API's traits facilities to create a custom plugin which supports your use case. stephenc provided some good guidance for others as they have started creating the tag discovery plugin(s). I've referenced him on this comment in case he can point you to those same suggestions.

          Alastair D'Silva added a comment - - edited

          The workaround mentioned above is almost good enough, if we could prefix the branch name with the remote name, it would remove the collisions and give the same behaviour as before, but maintained purely in Jenkins.

           

          (later) I'll log this as a separate request, as it's a different solution to the problem.

          Alastair D'Silva added a comment - - edited The workaround mentioned above is almost good enough, if we could prefix the branch name with the remote name, it would remove the collisions and give the same behaviour as before, but maintained purely in Jenkins.   (later) I'll log this as a separate request, as it's a different solution to the problem.

            Unassigned Unassigned
            evildeece Alastair D'Silva
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: