-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Critical
-
Component/s: gitlab-api-plugin, gitlab-branch-source-plugin
-
Environment:Jenkins 2.516.3
GitLab API Plugin 5.8.1-106.vef1de800710e
GitLab Branch Source Plugin 724.v6e30226050b_3
GitLab Plugin 1.9.9
The Jenkins environment used to work perfectly until very recently, when a plugin update completely broke things.
We have two branch sources very carefully curated to avoid overlaps. A parent group (call it parent-group) is one source, and one of its subgroups (let's call it parent-group/sub-group) is another.
Scanning for parent-group works just fine, with the same credentials (with access permissions which include read_user, etc.).
Scanning for parent-group/sub-group fails with the following exception:
org.gitlab4j.api.GitLabApiException: 403 Forbidden - Not authorized to access /api/v4/users at PluginClassLoader for gitlab-api//org.gitlab4j.api.AbstractApi.validate(AbstractApi.java:763) at PluginClassLoader for gitlab-api//org.gitlab4j.api.AbstractApi.get(AbstractApi.java:260) at PluginClassLoader for gitlab-api//org.gitlab4j.api.UserApi.getUser(UserApi.java:352) at PluginClassLoader for gitlab-branch-source//io.jenkins.plugins.gitlabbranchsource.helpers.GitLabOwner.fetchOwner(GitLabOwner.java:40) Caused: java.lang.IllegalStateException: Unable to fetch User at PluginClassLoader for gitlab-branch-source//io.jenkins.plugins.gitlabbranchsource.helpers.GitLabOwner.fetchOwner(GitLabOwner.java:48) at PluginClassLoader for gitlab-branch-source//io.jenkins.plugins.gitlabbranchsource.GitLabSCMNavigator.getGitlabOwner(GitLabSCMNavigator.java:208) at PluginClassLoader for gitlab-branch-source//io.jenkins.plugins.gitlabbranchsource.GitLabSCMNavigator.getGitlabOwner(GitLabSCMNavigator.java:201) at PluginClassLoader for gitlab-branch-source//io.jenkins.plugins.gitlabbranchsource.GitLabSCMNavigator.retrieveActions(GitLabSCMNavigator.java:408) at PluginClassLoader for scm-api//jenkins.scm.api.SCMNavigator.fetchActions(SCMNavigator.java:326) at PluginClassLoader for branch-api//jenkins.branch.OrganizationFolder.computeChildren(OrganizationFolder.java:481) at PluginClassLoader for cloudbees-folder//com.cloudbees.hudson.plugins.folder.computed.ComputedFolder.updateChildren(ComputedFolder.java:272) at PluginClassLoader for cloudbees-folder//com.cloudbees.hudson.plugins.folder.computed.FolderComputation.run(FolderComputation.java:170) at PluginClassLoader for branch-api//jenkins.branch.OrganizationFolder$OrganizationScan.run(OrganizationFolder.java:909) at hudson.model.ResourceController.execute(ResourceController.java:101) at hudson.model.Executor.run(Executor.java:454)
If I remove the /sub-group bit, the problem goes away.
Clearly this has been working for over a year, so it's very strange for it to suddenly start failing like this. As I mentioned: the PAT in use works just fine with the parent project.
UPDATE : Upon further investigation, it appears that the issue may have to do with the slash ( / ) in the subgroup separation is getting incorrectly URL-encoded as %2F:
# # From GitLab's logs # 172.20.7.65 - - [09/Oct/2025:07:26:12 +0000] "GET /api/v4/groups/parent-group%2Fsub-group HTTP/1.1" 404 33 "" "Jersey/2.47 (HttpUrlConnection 21.0.8)" - 172.20.7.65 - - [09/Oct/2025:07:26:12 +0000] "GET /api/v4/groups/parent-group%2Fsub-group HTTP/1.1" 404 33 "" "Jersey/2.47 (HttpUrlConnection 21.0.8)" - 172.20.7.65 - - [09/Oct/2025:07:26:12 +0000] "GET /api/v4/users?username=parent-group%2Fsub-group&page=1&per_page=1 HTTP/1.1" 403 68 "" "Jersey/2.47 (HttpUrlConnection 21.0.8)" -
Cheers!
