Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
Managed Master 2.107.3.4-rolling
Pipeline 2.5
Github Branch Source 2.3.5
pipeline-github-plugin 1.0
workflow-multibranch 2.18
disable-github-multibranch-status 1.1
Description
When a pull request from a different fork is created, all statuses get posted to the fork of the submitter, and not the target. This causes issues with the pull request, because on the Github PR page, there is seemingly no status reported by Jenkins.
My fork gshieh/my_code is trying to submit a change into TheCompany/my_code
I have an idea why this is occurring. The plugin is POST-ing to
/repos/gshieh/my_code/statuses/3776fe0c93c2588af558a1adb88918fd439524ee
not to
/repos/TheCompany/my_code/statuses/3776fe0c93c2588af558a1adb88918fd439524ee
Attachments
Activity
Gordon Shieh
created issue -
Gordon Shieh
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Description |
When a pull request from a different fork is created, all statuses get posted to the fork of the submitter, and not the target. This causes issues with the pull request, because on the Github PR page, there is seemingly no status reported by Jenkins. We're behind a private github enterprise, so I can only give an hypothetical example with URLs. My fork {{gshieh/my_code}} is trying to submit a change into {{TheCompany/my_code}} I have an idea why this is occurring. The plugin is POST-ing to {{/repos/gshieh/my_code/statuses/3776fe0c93c2588af558a1adb88918fd439524ee}} not to {{/repos/TheCompany/my_code/statuses/3776fe0c93c2588af558a1adb88918fd439524ee}} |
When a pull request from a different fork is created, all statuses get posted to the fork of the submitter, and not the target. This causes issues with the pull request, because on the Github PR page, there is seemingly no status reported by Jenkins. My fork {{gshieh/my_code}} is trying to submit a change into {{TheCompany/my_code}} I have an idea why this is occurring. The plugin is POST-ing to {{/repos/gshieh/my_code/statuses/3776fe0c93c2588af558a1adb88918fd439524ee}} not to {{/repos/TheCompany/my_code/statuses/3776fe0c93c2588af558a1adb88918fd439524ee}} |
Gordon Shieh
made changes -
| Environment |
Managed Master 2.107.3.4-rolling Pipeline 2.5 Github Branch Source 2.3.5 pipeline-github-plugin 2.0 |
Managed Master 2.107.3.4-rolling Pipeline 2.5 Github Branch Source 2.3.5 pipeline-github-plugin 1.0 |
So I remember this issue from early on in the plugins development, it's an issue with using forks vs creating a feature/bugfix/whatever branch in the target repository.
https://developer.github.com/v3/repos/statuses/
The GitHub statuses API is for adding statues to commits, and your commit is on your fork, not the target repository of the Pull Request. However your commit will be in the target repository once you merge the PR..
And the Jenkins Github Plugin probably doesn't have the permission/access to create statues on your fork. You could try adding the Jenkins SCM user as a collaborator to your fork with write access?
In an enterprise environment I would suggest you create a new feature branch instead of using a fork and do your work there. Security can be managed via protected branches etc..
Forks are great for open source projects where you don't want to give just everyone write access to your repo (even with protected branches, because they can create an unlimited number of branches, tags etc.)
https://help.github.com/articles/about-protected-branches/
Aaron Whiteside
added a comment - - edited So I remember this issue from early on in the plugins development, it's an issue with using forks vs creating a feature/bugfix/whatever branch in the target repository.
https://developer.github.com/v3/repos/statuses/
The GitHub statuses API is for adding statues to commits, and your commit is on your fork, not the target repository of the Pull Request. However your commit will be in the target repository once you merge the PR..
And the Jenkins Github Plugin probably doesn't have the permission/access to create statues on your fork. You could try adding the Jenkins SCM user as a collaborator to your fork with write access?
In an enterprise environment I would suggest you create a new feature branch instead of using a fork and do your work there. Security can be managed via protected branches etc..
Forks are great for open source projects where you don't want to give just everyone write access to your repo (even with protected branches, because they can create an unlimited number of branches, tags etc.)
https://help.github.com/articles/about-protected-branches/ Gordon Shieh
made changes -
| Environment |
Managed Master 2.107.3.4-rolling Pipeline 2.5 Github Branch Source 2.3.5 pipeline-github-plugin 1.0 |
Managed Master 2.107.3.4-rolling Pipeline 2.5 Github Branch Source 2.3.5 pipeline-github-plugin 1.0 workflow-multibranch 2.18 disable-github-multibranch-status 1.1 |
Gordon Shieh
added a comment - Sorry, I wasn't too clear that we are using the Multibranch Pipeline job. The status name from the Multibranch Pipeline: continuous-integration/jenkins/pr-head gets POST'd to /repos/TheCompany/my_code/statuses/3776fe0c93c2588af558a1adb88918fd439524ee.
Only appears that the Pipeline: Github plugin is POST'ing to user's fork.
Gordon Shieh
added a comment - Sorry, I wasn't too clear that we are using the Multibranch Pipeline job. The status name from the Multibranch Pipeline: continuous-integration/jenkins/pr-head gets POST'd to /repos/TheCompany/my_code/statuses/3776fe0c93c2588af558a1adb88918fd439524ee .
Only appears that the Pipeline: Github plugin is POST'ing to user's fork. 
Hi gordonshieh thanks for the bug report, I've created a GitHub issue to track this:
https://github.com/jenkinsci/pipeline-github-plugin/issues/30