-
Bug
-
Resolution: Unresolved
-
Major
-
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
Description |
Original:
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 {noformat} +refs/remotes/*:refs/remotes/*{noformat} > git ls-remote -h -t git://gitlab.ozlabs.ibm.com/aggregate/skiboot.git # timeout=30 Checking branches... Processed 0 branches 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'. First up, the '-h' switch restricts the list to only {noformat} 'refs/heads/*'{noformat} , while the branches we care about are in {noformat} 'refs/remotes/*'{noformat} . 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. |
New:
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 {noformat} +refs/remotes/*:refs/remotes/*{noformat} > 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 {noformat} 'refs/heads/*'{noformat} , while the branches we care about are in {noformat} 'refs/remotes/*'{noformat} . 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'. |
Assignee | Original: Mark Waite [ markewaite ] |