Multibranch pipline fails because TRIAGE enum doesn't exist

Using Jenkins Ask a question
1

Hello, I am using the newest version of Jenkins 2.407 and all plugins were just updated. The multibranch pipleline scan fails. You can see the log here: Scissors Scan Repository Log [Jenkins]
The stacktrace is this:

ERROR: [Fri Jun 02 22:20:37 CDT 2023] Could not fetch branches from source 3a13a261-7d78-40a8-b899-bc6bd04c5185
[Fri Jun 02 22:20:37 CDT 2023] Finished branch indexing. Indexing took 2.1 sec
FATAL: Failed to recompute children of Scissors
java.lang.IllegalArgumentException: No enum constant org.kohsuke.github.GHPermissionType.TRIAGE
	at java.base/java.lang.Enum.valueOf(Enum.java:273)
	at org.kohsuke.github.GHPermission.getPermissionType(GHPermission.java:55)
	at org.kohsuke.github.GHRepository.getPermission(GHRepository.java:1096)
	at org.jenkinsci.plugins.github_branch_source.GitHubSCMSource$1.fetch(GitHubSCMSource.java:1036)
	at org.jenkinsci.plugins.github_branch_source.GitHubSCMSourceRequest.getPermissions(GitHubSCMSourceRequest.java:450)
	at org.jenkinsci.plugins.github_branch_source.ForkPullRequestDiscoveryTrait$TrustPermission.checkTrusted(ForkPullRequestDiscoveryTrait.java:323)
	at org.jenkinsci.plugins.github_branch_source.ForkPullRequestDiscoveryTrait$TrustPermission.checkTrusted(ForkPullRequestDiscoveryTrait.java:310)
	at jenkins.scm.api.trait.SCMHeadAuthority.isTrusted(SCMHeadAuthority.java:101)
	at jenkins.scm.api.trait.SCMSourceRequest.isTrusted(SCMSourceRequest.java:213)
	at org.jenkinsci.plugins.github_branch_source.GitHubSCMSource$4.create(GitHubSCMSource.java:1270)
	at org.jenkinsci.plugins.github_branch_source.GitHubSCMSource$4.create(GitHubSCMSource.java:1264)
	at jenkins.scm.api.trait.SCMSourceRequest.process(SCMSourceRequest.java:339)
	at org.jenkinsci.plugins.github_branch_source.GitHubSCMSource.retrievePullRequest(GitHubSCMSource.java:1261)
	at org.jenkinsci.plugins.github_branch_source.GitHubSCMSource.retrieve(GitHubSCMSource.java:1099)
	at jenkins.scm.api.SCMSource._retrieve(SCMSource.java:372)
	at jenkins.scm.api.SCMSource.fetch(SCMSource.java:282)
	at jenkins.branch.MultiBranchProject.computeChildren(MultiBranchProject.java:654)
	at com.cloudbees.hudson.plugins.folder.computed.ComputedFolder.updateChildren(ComputedFolder.java:269)
	at com.cloudbees.hudson.plugins.folder.computed.FolderComputation.run(FolderComputation.java:167)
	at jenkins.branch.MultiBranchProject$BranchIndexing.run(MultiBranchProject.java:1057)
	at hudson.model.ResourceController.execute(ResourceController.java:101)
	at hudson.model.Executor.run(Executor.java:442)
Finished: FAILURE

I cannot find anything on Google with this stacktrace. Another multibranch pipeline on the system completes fine with the same credentials. I tried giving the token full permissions to everything and that didn’t change anything. I have admin role access on this repository. I’m not sure what to do here or if it’s a bug or what. Any help would be appreciated, thank you

2

Ok so I think I figured it out. I changed the “Discover pull requests from forks” to Nobody and it completed successfully. No idea what the issue actually was.

3

I think it might be a bug in hub4j, but at least should be reported to github_branch_source plugin.

4

Similar issue for us:

java.lang.IllegalArgumentException: No enum constant org.kohsuke.github.GHPermissionType.MAINTAIN

All attempts to create a new PR with the same hash failed. The only fix was to create a new PR. Somehow the Jenkins state was affected by this issue or caused the issue.

1 Like
5

This started for us over the weekend too, but with Peter’s error about MAINTAIN. Did this just start happening for everybody? I wonder if GitHub did some permission changes over the weekend? We’re trying to figure out the behavior still. Some people’s forked source branches are fine. Other people’s aren’t.

Switching to branch-based, rather than forked-repo, works around the issue by not executing this codepath.

6

Just started happening on ci.jenkins.io recently as well. First time I detected it was today. Visible in the repository scan log for the CI job that evaluates documentation site pull requests.

7

We think that we’ve found the solution with a pull request to the github-api library that is used in the GitHub API plugin. Once the library is released, it will need to be included in a new release of the GitHub API plugin and that plugin will need to be released.

A pre-release of the plugin with a pre-release of the library inside it has been deployed on ci.jenkins.io and seems to be working as expected.

8

GitHub reverted the REST API change that caused the damage. As far as we can tell, things are operating as expected again.