JENKINS-64662 Create GitHub App Credentials Binding to support owner override

[nrayapati]

Description

Create GitHub App Credentials Binding to support owner override
See JENKINS-64662 for further information.

Submitter checklist

• Link to JIRA ticket in description, if appropriate.
• Change is code complete and matches issue description
• Automated tests have been added to exercise the changes
• Reviewer's manual test instructions provided in PR description. See Reviewer's first task below.

Reviewer checklist

• Run the changes and verify that the change matches the issue description
• Reviewed the code
• Verified that the appropriate tests have been written or valid explanation given

Documentation changes

• Link to jenkins.io PR, or an explanation for why no doc changes are needed

Users/aliases to notify

@bitwiseman @timja

Testing Results

[nrayapati]

@bitwiseman @timja thoughts on this change?

[nrayapati]

Really appreciate any feedback and steps to get this merged and released soon. Thank you!

[bitwiseman]

I have not updated this to deal with autoformatting.

The steps needed:

$ git merge task/formatting-base
# resolve conflicts
$ mvnd spotless:apply && git commit -am "Apply autoformatting" && git merge -Xours upstream/master

[nrayapati]

@bitwiseman Thank you for the feedback and addressed it.

[carlossg]

if you are just going to keep one token wouldn't a Map make more sense and be more clear?

[nrayapati]

I tried Map and changed it to List, I think I did that to avoid adding overrides to serialize/deserialize as this is transient field.

I think it is good to have that owner field with actual class just in case if we are going to use this token for future use cases across other classes.

[bitwiseman]

I tried Map and changed it to List, I think I did that to avoid adding overrides to serialize/deserialize as this is transient field.

Not sure why this is a reason to use List instead of Map.

I think it is good to have that owner field with actual class just in case if we are going to use this token for future use cases across other classes.

I'm not sure what you mean here.

[carlossg]

In my case this doesn't solve the underlying issue, in a multibranch pipeline job I would still need one credential per organization to do the repository scan.

[nrayapati]

@bitwiseman Any other thoughts on this change?, looks like we have closed the other PR that carlossg proposed

[bitwiseman]

Similar to other recent changes, we should look at using concurrent hash map instead.

[ebirn]

Hi all,
Thanks for that work! I'm not a Jenkins developer, but highly interested in getting this feature integrated.
(My use-case is a single Github app by our institution, for internal customers in different Github Orgs)
I would like to provision the Github App Credentials once in Jenkins, and reuse it in the context of different Github Org owners.

How can I help to get this merged and released?
Best,
Erich

[jglick]

Not sure I see the point of this. You can already specify an owner…?

[jglick]

Perhaps #527 covers your requirement.

[Seros]

Hi, is there any way to support here? We would like to have this feature as well especially to have actual credential binding for the GitHub App access token and to not have to use usernamePassword binding for this which btw I haven't found documented anywhere but just read about in the linked issue. That could probably be helpful for others as well.

[nrayapati]

Closing this issue as it has been addressed in a more comprehensive solution.

Created PR #875 which implements Multi-Organization GitHub App Credentials that support:

• Single credential working across multiple organizations where the GitHub App is installed
• Seamless integration with Organization Folders, Multibranch Pipelines, and regular Pipelines
• Pipeline credentials binding for both automatic and manual modes
• Backward compatibility with existing GitHub App credentials

This provides a complete solution for multi-organization workflows without requiring duplicate credentials.

See: #875