Ruleset "Status checks that are required" matches the wrong source #199130

oliviertassinari · 2026-06-15T21:53:25Z

oliviertassinari
Jun 15, 2026

🏷️ Discussion Type

Bug

Reproduction

Take mui/mui-x#22792, the last commit is mui/mui-x@7e38354. The CI checks passes, gh api repos/mui/mui-x/commits/7e38354625ec2f55af3e9bdc7be7a57038d5354b/status returns:

{
  "state": "success",
  "statuses": [
    {
      "url": "https://api.github.com/repos/mui/mui-x/statuses/7e38354625ec2f55af3e9bdc7be7a57038d5354b",
      "avatar_url": "https://avatars.githubusercontent.com/oa/4808?v=4",
      "id": 48971127823,
      "node_id": "SC_kwDOD4Lzcc8AAAALZugcDw",
      "state": "success",
      "description": "Your tests passed on CircleCI!",
      "target_url": "https://circleci.com/gh/mui/mui-x/861543",
      "context": "ci/circleci: test_charts_benchmark",
      "created_at": "2026-06-15T15:18:39Z",
      "updated_at": "2026-06-15T15:18:39Z"
    },

So the checks pass from the CircleCI Oauth app.

We also have rulesets for this repository https://github.com/mui/mui-x/rules/549908. There, it expects the checks to come from the CircleCI GitHub App.

Actual

In practice, people can't merge, but the UI of the PR makes it look like the checks pass:

mui/mui-x#22817

It's only once you try to merge the PR that it returns an obscure error message:

Expected

The UI above is wrong; it should clearly show that the checks are not met.

For example, it could look like this:

and the merge button could be blocked.

2026-06-15T21:54:10Z

github-actions[bot]
Bot Jun 15, 2026

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

Your input will be carefully reviewed and cataloged by members of our product teams.
- Due to the high volume of submissions, we may not always be able to provide individual responses.
- Rest assured, your feedback will help chart our course for product improvements.
Other users may engage with your post, sharing their own perspectives or experiences.
GitHub staff may reach out for further clarification or insight.
- We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

Upvote and comment on other user feedback Discussions that resonate with you.
Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

0 replies

SeaWalsh1980 · 2026-10-31T21:31:01Z

SeaWalsh1980
Oct 31, 2026

We hit the same thing and tested the merge itself, on a private repository in a Team organization.

A throwaway GitHub App, not the source any rule names, posted check runs under the names of four required checks. Each check is bound to a specific App in a branch ruleset. The App also approved the PR.

What the UI and API reported:

green rows marked Required
"All checks have passed"
a Merge button that looked active, on an admin and a non-admin account
isRequired: true on those check runs in GraphQL

What a merge did: the App's PUT /repos/{owner}/{repo}/pulls/{n}/merge returned HTTP 405:

Repository rule violations found. Required status checks "…" were not set by the expected GitHub apps.

Commit statuses from the same App got the same refusal. mergeStateStatus read BLOCKED when we checked it.

So the source binding did hold, and the display is what misleads: nothing on the merge box says the result came from the wrong source. A person, or a tool reading isRequired, would conclude the requirement is met.

It would help if the row showed that the result doesn't count, for example "from an unexpected source", and if isRequired or a new field said whether this result satisfies the requirement.

Not tested: a commit status posted by a user with write access rather than an App.

0 replies

Nour-yahyaoui · 2026-10-31T23:13:13Z

Nour-yahyaoui
Oct 31, 2026

Interesting find! The distinction between a successful commit status and the expected GitHub App identity seems to be the key issue here.

From the reproduction, CircleCI OAuth reports the status as success, but the ruleset expects the check to originate from the CircleCI GitHub App. This means the check can appear successful in the PR UI while still failing the ruleset's required source validation during merge.

I think the UI should distinguish between:

A check that completed successfully.
A check that satisfies the required ruleset configuration, including its expected GitHub App.

Showing a green checkmark without making that distinction is misleading, especially when the merge is ultimately blocked.

Ideally, GitHub should surface the exact mismatch directly in the PR checks section and disable the merge action with a clear explanation instead of waiting until the user attempts to merge.

Thanks for providing such a detailed reproduction!

1 reply

queenofcorgis Nov 3, 2026
Maintainer

@Nour-yahyaoui, thanks for participating in GitHub Discussions!

Please note: we’ve clarified our stance on using generative AI tools like ChatGPT within our Community via this announcement. Please review the guidelines to ensure your post meets them as failure to adhere to those rules can result in action taken by our moderator team.

You can read our updated Code of Conduct and the announcement for more details.

Please feel encouraged to continue engaging in Discussions as your authentic self though. We appreciate you being a part of the Community 🌟

Keepstacking22 · 2026-10-31T23:58:36Z

Keepstacking22
Oct 31, 2026

Modifying a GitHub App registration

After registering a GitHub App, you can make changes to it.

About GitHub App modifications

You can modify your GitHub App registration to change any of the settings that were selected when the app was initially registered. For more information about the settings you can select while registering a GitHub App, see Registering a GitHub App.

For example, you can change the name and description of your app, the permissions granted to your app, the webhooks your app subscribes to, or the visibility of your app.

You can also choose to test new optional features for your GitHub App. See Activating optional features for GitHub Apps.

Navigating to your GitHub App settings

To modify a GitHub App, first navigate to the app settings page.

In the upper-right corner of any page on GitHub, click your profile picture.
Navigate to your account settings.
- For an app owned by a personal account, click Settings.
- For an app owned by an organization:
  1. Click Your organizations.
  2. To the right of the organization, click Settings.
In the left sidebar, click Developer settings.
In the left sidebar, click GitHub Apps.
To the right of the GitHub App you want to modify, click Edit.

Changing the basic information of a GitHub App

You can change the basic information of your GitHub App, like the name of the app, the description of the app, and the homepage URL of the app.

Navigate to the settings page for the app you'd like to modify. For more information, see Navigating to your GitHub App settings in this article.
Under "Basic information," modify the GitHub App information that you'd like to change.
Click Save changes.

Requesting user authorization (OAuth) during installation

You can prompt users to authorize your GitHub App when they install it and generate a user access token. When you request user authorization (OAuth) during installation, you must also provide a callback URL where the user will be redirected after they authorize the installation. See Generating a user access token for a GitHub App.

Navigate to the settings page for the app you'd like to modify. For more information, see Navigating to your GitHub App settings in this article.
Under "Identifying and authorizing users," select or deselect Request user authorization (OAuth) during installation.
Under "Callback URL," enter the full URL to redirect to after a user authorizes the installation.

Enabling or disabling the device flow

You can use the device flow to authorize users for a headless app like a CLI tool or Git credential manager. For more information about using the device flow with GitHub Apps, see Generating a user access token for a GitHub App.

Navigate to the settings page for the app you'd like to modify. For more information, see Navigating to your GitHub App settings in this article.
Under "Identifying and authorizing users," select or deselect Enable Device Flow.

Adding or updating a setup URL

You can redirect people to a specific URL after they install your app. See Registering a GitHub App.

If you select Request user authorization (OAuth) during installation, you will not be able to enter a setup URL. Users will instead be redirected to the Callback URL as part of the authorization flow, where you can describe additional setup. See About the user authorization callback URL.

Navigate to the settings page for the app you'd like to modify. For more information, see Navigating to your GitHub App settings in this article.
Under "Post installation," in the "Setup URL" field, enter the URL where you'd like to redirect users after they install your app.
Optionally, if you want to redirect users to the setup URL after they update an installation, select Redirect on update. An update includes adding or removing a repository for an installation. If "Setup URL" is blank, this will be ignored.

Changing the permissions of a GitHub App

You can change the access permissions that are granted to your GitHub App using the following steps.

When you add new repository or organization permissions for an app, each account where the app is installed will need to approve the new permissions. When you add account permissions for an app, each user that has authorized the app will need to approve the permission changes. In both cases, GitHub will send an email to each organization owner or user, notifying them of the request to update the app's permissions. Updated permissions won't take effect on an installation or user authorization until the new permissions are approved. You can use the installation webhook to find out when people accept new permissions for your app.

If you remove permissions or webhooks from your GitHub App, the changes will take effect immediately. If you remove permissions that were previously granted to your app, the app will no longer be able to access those resources.

Changing the permissions of an app may also change the webhooks that your app can subscribe to and the actions that your app can take with the API. See Choosing permissions for a GitHub App.

Navigate to the settings page for the app you'd like to modify. For more information, see Navigating to your GitHub App settings in this article.
In the GitHub Apps settings sidebar, click Permissions & events.
Under the sections "Repository permissions," "Organization permissions," and "Account permissions," modify the permissions you'd like to change. For each type of permission, select either "Read-only," "Read and write," or "No access" from the dropdown. See Choosing permissions for a GitHub App.
Optionally, under "Add a note to users," add a note telling your users why you are changing the permissions that your GitHub App requests.
Click Save changes.

Activating or deactivating the GitHub App webhook

You can configure your GitHub App to receive webhooks for specific events on GitHub and automatically take action on them. See Using webhooks with GitHub Apps.

Navigate to the settings page for the app you'd like to modify. For more information, see Navigating to your GitHub App settings in this article.
Under "Webhook," to enable or disable the webhook, select or deselect Active.
If you selected Active in the previous step, under "Webhook URL," enter the URL that GitHub should send webhook events to.
Optionally, if you selected Active in the previous step, under "Webhook secret," enter a secret token to secure your webhooks. GitHub highly recommends that you set a webhook secret.

Changing the webhook event subscriptions of a GitHub App

You can change the webhook events that a GitHub App subscribes to using the following steps.

The specific webhook events that you can select for your GitHub App registration are determined by the type of permissions you selected for your app. You will first need to select the permissions you would like your app to have, and then you can subscribe your app to webhook events that are related to that set of permissions. See Using webhooks with GitHub Apps.

Navigate to the settings page for the app you'd like to modify. For more information, see Navigating to your GitHub App settings in this article.
Activate the GitHub App webhook. See Activating or deactivating the GitHub App webhook in this article.
In the GitHub Apps settings sidebar, click Permissions & events.
Under the sections "Repository permissions," "Organization permissions," and "Account permissions," select the permissions that are required for the events your app will subscribe to. See Changing the permissions of a GitHub App.
Under "Subscribe to Events," select the webhook events you would like your GitHub App to receive.
Click Save changes.

Changing the visibility of a GitHub App

You can change the visibility settings of your GitHub App to control who can install it. Public apps cannot be made private if they're installed on other accounts. See Making a GitHub App public or private.

Navigate to the settings page for the app you'd like to modify. For more information, see Navigating to your GitHub App settings in this article.
In the left sidebar, click Advanced.
Under "Danger zone," depending on the current visibility of your GitHub App, click either Make public or Make private.

0 replies

Navigation Menu

GitHub Community

Ruleset "Status checks that are required" matches the wrong source #199130

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 4 comments 1 reply

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

GitHub Community

Ruleset "Status checks that are required" matches the wrong source #199130

Uh oh!

Uh oh!

oliviertassinari Jun 15, 2026

🏷️ Discussion Type

Reproduction

Actual

Expected

Replies: 4 comments · 1 reply

Uh oh!

github-actions[bot] Bot Jun 15, 2026

Uh oh!

SeaWalsh1980 Oct 31, 2026

Uh oh!

Nour-yahyaoui Oct 31, 2026

Uh oh!

queenofcorgis Nov 3, 2026 Maintainer

Uh oh!

Keepstacking22 Oct 31, 2026

Modifying a GitHub App registration

About GitHub App modifications

Navigating to your GitHub App settings

Changing the basic information of a GitHub App

Requesting user authorization (OAuth) during installation

Enabling or disabling the device flow

Adding or updating a setup URL

Changing the permissions of a GitHub App

Activating or deactivating the GitHub App webhook

Changing the webhook event subscriptions of a GitHub App

Changing the visibility of a GitHub App

oliviertassinari
Jun 15, 2026

Replies: 4 comments 1 reply

github-actions[bot]
Bot Jun 15, 2026

SeaWalsh1980
Oct 31, 2026

Nour-yahyaoui
Oct 31, 2026

queenofcorgis Nov 3, 2026
Maintainer

Keepstacking22
Oct 31, 2026