Skip to content
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

Support for multibranch pipelines outside of GitHub org that use GitHub repo and app credentials #385

Closed
michalszelagsonos opened this issue May 12, 2024 · 14 comments
Labels
enhancement New feature or request

Comments

@michalszelagsonos
Copy link

michalszelagsonos commented May 12, 2024

What feature do you want to see added?

I have a very large org, 1000+ repositories. In this org, we have many teams where each team is grouping their multibranch pipeline projects into folders and each one uses GitHub repo as a source. This works well since each team creates a project that maps to their repo and there's no coupling between them and no opportunity to potentially misconfigure discovery and ingest 1000+ projects into Jenkins.

This also reduces the load on the API when projects changes are applied since each projects triggers a rescan of that repo, not of the entire org.

I'd love to start using checks API but to do that I would need to roll all these projects under a single org in Jenkins and manage 1 config for them all which is very problematic at the org our size. What also complicates things is that we have multiple jenkins projects mapping to a single repo but using different Jenkinsfile and job configuration. This allows us to run different workloads on different triggers and maintain simple pipelines from a single repo that logically maps to these jobs. Think 3-4 projects in a repo, 1 that supports PR pipelines, 1 to do maintenance and infra tasks, 1 to enable additional automation in other scenarios.

I would love to see support in this plugin where the projects can define SCM to be a github repo, using github app authentication, and be able to post checks but not have to be discovered through a github org, since that imposes a lot of restrictions on structuring projects and forces me to adopt a very restrictive structure and frankly doesn't work for us. This kind of flexibility would really unlock more adoption by larger organizations that have large GitHub orgs and have to manage API access rates.

Upstream changes

No response

Are you interested in contributing this feature?

No response

@michalszelagsonos michalszelagsonos added the enhancement New feature or request label May 12, 2024
@timja
Copy link
Member

timja commented May 12, 2024

It doesn't require to be using a GitHub org, multi branch pipelines work just fine.

What makes you think it doesn't? Are you hitting an issue?

@michalszelagsonos
Copy link
Author

Yes, I am hitting an issue. I am on plugin version 2.0.0. This is the call I am making from the pipeline:

publishChecks name: 'PR Label Check', title: 'PR Label Check pending title', summary: 'PR Label check pending summary',
                    text: 'PR Label check description pending',
                    detailsURL: env.JOB_URL,
                    status: "IN_PROGRESS",
                    conclusion: "NONE",
                    actions: [[label:'Re-run', description:'Re-run the job', identifier:'rerequested']]

I am getting the following error:

[GitHub Checks] Failed Publishing GitHub checks: org.kohsuke.github.HttpException: {"message":"Resource not accessible by integration","documentation_url":"https://docs.github.com/rest/checks/runs#create-a-check-run"}

The job is using a github app for credentials in the branch source section. Am I missing any additional configuration in Jenkins?

@timja
Copy link
Member

timja commented May 13, 2024

which plugin version at 2.0.0? github checks doesn't have a 2.0.0 version I can see.

Resource not accessible by integration

This normally means the permissions on your app aren't right, see https://github.com/jenkinsci/github-checks-plugin#getting-started and make sure you've given it Read/Write on Checks

@michalszelagsonos
Copy link
Author

I have all of the permissions set at the required level, or higher. Here's my app config permissions for the items mentioned in the guide:

  • Checks: read & write
  • Contents: read & write
  • Metadata: read
  • Pull requests: read & write

I have been using this app to post status checks from my jobs and make releases by minting a token from a private key and that works. I am pretty confident the app is configured correctly. Anything else I need to configure in the global Jenkins config?

@timja
Copy link
Member

timja commented May 13, 2024

status checks are different to checks, status only requires a personal access token.

How is your job configured for retrieving the pipeline?

@michalszelagsonos
Copy link
Author

michalszelagsonos commented May 13, 2024

The job is configured as:

  • GitHub branch source
  • Credentials: the github app with permissions set
  • Repository URL: https://github.com/...
  • Checkout over SSH using SSH private key credentials
  • Enabled: Skip GitHub Branch Source notifications in Status Checks to disable default Jenkins status check
  • Build configuration: By Jenkinsfile

@timja
Copy link
Member

timja commented May 13, 2024

possible to take a screenshot of the configuration? (redacting anything you aren't comfortable sharing)

@michalszelagsonos
Copy link
Author

Here are the screenshots of the config of all things that are non-default. The branch source credentials are configured at the global scope as a github app. The checkout credentials are also at global scope, username + private key type.

The job works, checkout works, Jenkins can scan the repo with the provided creds and discovers everything. Note, the job is configured inside a folder, it is not associated with github org folder.

screenshot1
config1

screenshot2
config2

screenshot3
config3

@timja
Copy link
Member

timja commented May 13, 2024

I've just tested this with a multi branch pipeline and it all worked fine for me:

image

Repo: timja-org/junit-attachments-test#5

@michalszelagsonos
Copy link
Author

michalszelagsonos commented May 13, 2024

Thanks for trying this out. So, what else remains that could be different between your environment and mine? The app config in Jenkins? The app permissions on GitHub? My repo is private vs. public? Anything else that you can think of?

@timja
Copy link
Member

timja commented May 13, 2024

Normally its either that the app hasn't been installed properly (i.e. install hasn't been clicked on the app after creating) or missing permissions..

Have you tried validating the app by clicking I think it's 'Test connection' on the Jenkins credential side.

@michalszelagsonos
Copy link
Author

michalszelagsonos commented May 13, 2024

Yes, when I click "Test connection" it works. I also see Jenkins say it is using it to scan the repo when I change the config of the job and that works so that suggests the app credentials are working. This is from the repo rescan log:

15:24:51 Connecting to https://api.github.com/ using ***/****** (GitHub app credentials corresponding to *** Jenkins)
Examining [***/***](https://github.com/***)

I followed the directions from the page referenced above, including this step to convert the key:

openssl pkcs8 -topk8 -inform PEM -outform PEM -in key-in-your-downloads-folder.pem -out converted-github-app.pem -nocrypt

I wonder if there is some other set of permissions that is preventing the app from accessing the API. I didn't create the app, it was made for me by my org admin but I can manage it's config which is how I can access and change permissions on it. There is obviosly a detail somewhere in here that is making a difference.

@timja
Copy link
Member

timja commented May 13, 2024

Your permissions look fine, for reference this is what mine looks like but I can't see anything important in there:

image

@michalszelagsonos
Copy link
Author

Solved!

I ended up reaching out to my org admin for a consultation and turns out that when I changed GH app permissions, that triggers an approval process on admin side and until they click to approve, the app is not granted the necessary permissions. The terrible UX part on GitHub side is that there is no mention of a pending approval in the UI, the app settings show the permissions despite them not being in effect. Once my org admin approved the change, this works now.

Moral of the story, if you're using an app in an org where an admin created the app and gave you control permissions, make sure they approve any permission changes first, or this integration will not work.

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

No branches or pull requests

2 participants