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.