Skip to content

Allow GitHub app to be installed in multiple orgs #290

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

timja
Copy link
Member

@timja timja commented Mar 24, 2020

Description

See #269 (comment)

To test it you need multiple organisation, ideally with private repos on both as public repos can be read even if haven't granted access, install the app to both organisations and follow the steps in the documentation

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
    doc is in the repo

Users/aliases to notify

@jglick @bitwiseman @dwnusbaum

}
GHAppInstallation appInstallation;
if (appInstallations.size() == 1) {
appInstallation = appInstallations.get(0);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not verifying the owner?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've made an assumption that most installations only work with one org, so I've made it an advanced field and by default if and only if there's one installation the plugin will just pick that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I get that, I am just saying that in case you did specify an owner, and there is exactly one installation, we are not verifying that the installation is in fact from that owner. Which feels wrong.

@@ -87,7 +87,8 @@ Fill out the form:
- App ID: the github app ID, it can be found in the 'About' section of your GitHub app in the general tab.
- API endpoint (optional, only required for GitHub enterprise this will only show up if a GitHub enterprise server is configured).
- Key: click add, paste the contents of the converted private key
- Passphrase: do not fill this field, it will be ignored
- Advanced: (optional) If you've installed your same GitHub app on multiple organisations you need the next step
* Owner: the name of the organisation or user, i.e. jenkinsci for https://github.com/jenkinsci
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So under this approach you cannot reuse the Jenkins credentials object across orgs, and you need to duplicate the private key. Not as smooth as having Jenkins figure out which installation to work with, but better than nothing, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah I couldn't see a way to do that, as we don't have the context from the build job at all

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, it would be a more intrusive patch since you would need to do something along the lines of defining a thread-local org and setting this from a new overload of Connector.connect which passes a repoOwner and then switching as many callers as possible to the new overload. Not sure it is worth the effort since I presume the common case is for the Jenkins installation to be used on only a single org.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure it is worth the effort since I presume the common case is for the Jenkins installation to be used on only a single org.

What about for GitHub Enterprise? It doesn't seem to be possible to install an app at the Enterprise level. My Jenkins instance works on repos across many organizations in a GitHub Enterprise instance.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not have GHE to test against but in that case with the current patch you would need to first install the app in each such org, then create a separate Jenkins credentials item for each installation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, those were all public repos.

is there any way that we can get this owner based on the job config as it would already have the github repo information ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The credential isn’t tied to a job it’s independent, not safely, there may be some possible hacks to do it though

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My company uses Jenkins in a similar fashion as the company described by @nrayapati.

We deployed a single jenkins GitHub App that may be installed by any organization on our GHE instance. There are several hundred such organizations.

We allow our engineers to create jobs as needed within their own Jenkins folders and leverage the single GitHub App Credential.

Since any engineer can install our GitHub App on their organization, and any engineer can create an organization, we would be in the situation of needing to create a Credential for every organization as it's created.

I, too, would like to see support for a single global Credential to work for jobs across multiple organizations.

@nrayapati can you please file a Jira ticket (As this PR has already been merged and released) so that we can centralize the discussion about this use case on that ticket?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we just use the org name in repo instead of the org name in credential config?

Co-Authored-By: Liam Newman <[email protected]>

) {
GitHubAppCredentials gitHubAppCredential = new GitHubAppCredentials(
CredentialsScope.GLOBAL, "test-id-not-being-saved", null,
appID, Secret.fromString(privateKey)
);
gitHubAppCredential.setApiUri(apiUri);
gitHubAppCredential.setOwner(owner);
Copy link

@robbiemcmichael robbiemcmichael Mar 25, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Commenting here since the CredentialsScope.GLOBAL part is just above this:

Do you know if it's possible to use system scope credentials with the branch source plugin? One issue we ran into with our credentials plugin was making the credentials for an org only available to the builds within that org.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not possible to use system scope credentials, but you can define credentials on an org folder so they are not accessible outside that folder.

@bitwiseman bitwiseman closed this Mar 31, 2020
@bitwiseman bitwiseman reopened this Mar 31, 2020
@bitwiseman
Copy link
Contributor

What the...? Not sure why these tests started failing.

}
GHAppInstallation appInstallation;
if (appInstallations.size() == 1) {
appInstallation = appInstallations.get(0);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I get that, I am just saying that in case you did specify an owner, and there is exactly one installation, we are not verifying that the installation is in fact from that owner. Which feels wrong.

timja and others added 4 commits March 31, 2020 19:29
…GitHubAppCredentials/help-owner.html

Co-Authored-By: Jesse Glick <[email protected]>
…ithub.com:timja/github-branch-source-plugin into allow-github-app-to-be-installed-in-multiple-orgs
Copy link
Member

@oleg-nenashev oleg-nenashev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure "owner" is a correct terminology here, because it might be confused with the GitHub App owner (each app is formally owned by a GitHub account). Maybe installationTarget or targetAccount is better

@@ -87,7 +87,8 @@ Fill out the form:
- App ID: the github app ID, it can be found in the 'About' section of your GitHub app in the general tab.
- API endpoint (optional, only required for GitHub enterprise this will only show up if a GitHub enterprise server is configured).
- Key: click add, paste the contents of the converted private key
- Passphrase: do not fill this field, it will be ignored
- Advanced: (optional) If you've installed your same GitHub app on multiple organisations you need the next step
* Owner: the name of the organisation or user, i.e. jenkinsci for https://github.com/jenkinsci
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good enough IMHO

@timja
Copy link
Member Author

timja commented Apr 2, 2020

I am not sure "owner" is a correct terminology here, because it might be confused with the GitHub App owner (each app is formally owned by a GitHub account). Maybe installationTarget or targetAccount is better

possibly but I copied the text that is used for it when configuring it in a pipeline organisation,

the help text and docs explain it better

@bitwiseman bitwiseman merged commit 28f9a64 into jenkinsci:master Apr 7, 2020
@jglick jglick mentioned this pull request Apr 7, 2020
8 tasks
@nrayapati
Copy link
Member

nrayapati commented Apr 25, 2020

Sorry for making a comment on this closed PR: but I had to make a comment here.

#290 (comment)

Let me know your thoughts, I can log a JIRA with more details. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants