Jenkins: 2.289.1
OS: Linux - 5.4.0-70-generic
---
...
gitlab-plugin:1.5.20
What Operating System are you using (both controller, and any agents involved in the problem)?
Linux 5.4.0-70-generic #78-Ubuntu SMP Fri Mar 19 13:29:52 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Reproduction steps
Create Gitlab repository with User A, give permissions to User B.
Fork Gitlab with User B.
Ensure User A does not have access to User B's fork.
Configure Jenkins to use a Gitlab triggered pipeline using a webhook, make sure updateGitlabCommitStatus is used at least once. Use the Gitlab Personal Access Token of User A. Set the webhook to trigger on Merge Request open and push events, so that it is triggered soon as a Merge Request is opened on the target/upstream repository.
Let User B create a branch with some changes in their fork.
Open a Merge Request with User B on the target/upstream repository using this fork's branch.
Gitlab will now trigger the webhook. Jenkins will attempt to update the commit status using updateGitlabCommitStatus.
Results
Expected result:
The updateGitlabCommitStatus is performed on the target/upstream repository, and the commit (pipeline) status is updated successfully.
Actual result:
The updateGitlabCommitStatus is not performed. The Gitlab plugin fails to retrieve the project ids because it tries to access the source and not the target's project id. In this case, the source is the fork project (from User B) and returns an error since User A does not have access to User B's fork. The relevant API call:
Retrieving gitlab project ids
Aug 16, 2021 11:29:07 AM FINEST com.dabsquared.gitlabjenkins.gitlab.api.impl.ResteasyGitLabClientBuilder
Call GitLab:
HTTP method: GET
URL: https://gitlab.com/api/v4/projects/.../repository/commits/...
Request headers: [
Accept = [application/json],
PRIVATE-TOKEN = [****FILTERED****]
]
The ... here seems to be the wrong project id. I assume the project id should be the project.id property (e.g. the target/upstream repository) from the MergeRequest object. Instead, it uses the object_attributes.source.id property.
In any case, the result is of course a 404, because the fork ("source project") is not accessible with the Personal Access Token that the plugin uses (User A):
Got response from GitLab:
URL: https://gitlab.com/api/v4/projects/.../repository/commits/...
Status: 404 Not Found
I'm not quite sure why this code is there, I'm sure there's a reason, but I would expect the code to either do that and on failure (in this case) fall back to the "target" project id, or to not query the source project id at all (though there's probably a reason for this).
Unfortunately with a team of developers using a fork strategy keeping changes in their own fork branches, and then opening up MRs in the target/upstream repository, this completely breaks the pipeline statuses.
jsight
commented
9 months ago
Version report
Jenkins and plugins versions report:
Reproduction steps
updateGitlabCommitStatusis used at least once. Use the Gitlab Personal Access Token of User A. Set the webhook to trigger on Merge Request open and push events, so that it is triggered soon as a Merge Request is opened on the target/upstream repository.updateGitlabCommitStatus.Results
Expected result:
The
updateGitlabCommitStatusis performed on the target/upstream repository, and the commit (pipeline) status is updated successfully.Actual result:
The
updateGitlabCommitStatusis not performed. The Gitlab plugin fails to retrieve the project ids because it tries to access the source and not the target's project id. In this case, the source is the fork project (from User B) and returns an error since User A does not have access to User B's fork. The relevant API call:The
...here seems to be the wrong project id. I assume the project id should be theproject.idproperty (e.g. the target/upstream repository) from theMergeRequestobject. Instead, it uses theobject_attributes.source.idproperty.In any case, the result is of course a 404, because the fork ("source project") is not accessible with the Personal Access Token that the plugin uses (User A):
The offending code seems to be located here:
https://github.com/TestYourLuck/gitlab-plugin/blob/ee4c3d62ff31b3766a396cf6744e45148b183634/src/main/java/com/dabsquared/gitlabjenkins/util/CommitStatusUpdater.java#L119
I'm not quite sure why this code is there, I'm sure there's a reason, but I would expect the code to either do that and on failure (in this case) fall back to the "target" project id, or to not query the source project id at all (though there's probably a reason for this).
Unfortunately with a team of developers using a fork strategy keeping changes in their own fork branches, and then opening up MRs in the target/upstream repository, this completely breaks the pipeline statuses.