app: Branch protection rules are not working anymore.

Problem Description

I just created a new repository with the same config file that I use for all of my repositories and noticed that although the configs are the same, branch protection rules are not working. Any help is appreciated. To reproduce, you can try creating a new repo from the default settings in the README file. I am attaching my current config below

# These settings are synced to GitHub by https://probot.github.io/apps/settings/

repository:
  # See https://docs.github.com/en/rest/reference/repos#update-a-repository for all available settings.

  # The name of the repository. Changing this will rename the repository
  name: store-api

  # A short description of the repository that will show up on GitHub
  description: Store related apis

  # A URL with more information about the repository
  homepage: https://example.github.io/

  # A comma-separated list of topics to set on the repository
  topics: store, marketplace-integration, order

  # Either `true` to make the repository private, or `false` to make it public.
  private: true

  # Either `true` to enable issues for this repository, `false` to disable them.
  has_issues: false

  # Either `true` to enable projects for this repository, or `false` to disable them.
  # If projects are disabled for the organization, passing `true` will cause an API error.
  has_projects: false

  # Either `true` to enable the wiki for this repository, `false` to disable it.
  has_wiki: false

  # Either `true` to enable downloads for this repository, `false` to disable them.
  has_downloads: false

  # Updates the default branch for this repository.
  default_branch: develop

  # Either `true` to allow squash-merging pull requests, or `false` to prevent
  # squash-merging.
  allow_squash_merge: false

  # Either `true` to allow merging pull requests with a merge commit, or `false`
  # to prevent merging pull requests with merge commits.
  allow_merge_commit: true

  # Either `true` to allow rebase-merging pull requests, or `false` to prevent
  # rebase-merging.
  allow_rebase_merge: false

  # Either `true` to enable automatic deletion of branches on merge, or `false` to disable
  delete_branch_on_merge: false

  # Either `true` to enable automated security fixes, or `false` to disable
  # automated security fixes.
  enable_automated_security_fixes: false

  # Either `true` to enable vulnerability alerts, or `false` to disable
  # vulnerability alerts.
  enable_vulnerability_alerts: false

# Labels: define labels for Issues and Pull Requests
labels:
  - name: fix
    color: '#E1A296'
    description: A label used to mark fixes for automatic release notes generation.

  - name: feature
    # If including a `#`, make sure to wrap it with quotes!
    color: '#336699'
    description: A label used to mark features for automatic release notes generation.

# Collaborators: give specific users access to this repository.
# See https://docs.github.com/en/rest/reference/repos#add-a-repository-collaborator for available options
collaborators:
  # - username: bkeepers
  #   permission: push
  # - username: hubot
  #   permission: pull

  # Note: `permission` is only valid on organization-owned repositories.
  # The permission to grant the collaborator. Can be one of:
  # * `pull` - can pull, but not push to or administer this repository.
  # * `push` - can pull and push, but not administer this repository.
  # * `admin` - can pull, push and administer this repository.
  # * `maintain` - Recommended for project managers who need to manage the repository without access to sensitive or destructive actions.
  # * `triage` - Recommended for contributors who need to proactively manage issues and pull requests without write access.

# See https://docs.github.com/en/rest/reference/teams#add-or-update-team-repository-permissions for available options
teams:
  - name: CodeReview
    # The permission to grant the team. Can be one of:
    # * `pull` - can pull, but not push to or administer this repository.
    # * `push` - can pull and push, but not administer this repository.
    # * `admin` - can pull, push and administer this repository.
    # * `maintain` - Recommended for project managers who need to manage the repository without access to sensitive or destructive actions.
    # * `triage` - Recommended for contributors who need to proactively manage issues and pull requests without write access.
    permission: admin
  - name: DevTeam
    permission: push
  - name: PlatformTeam
    permission: admin

branches:
  - name: develop
    # https://docs.github.com/en/rest/reference/repos#update-branch-protection
    # Branch Protection settings. Set to null to disable
    protection:
      # Required. Require at least one approving review on a pull request, before merging. Set to null to disable.
      required_pull_request_reviews:
        # The number of approvals required. (1-6)
        required_approving_review_count: 1
        # Dismiss approved reviews automatically when a new commit is pushed.
        dismiss_stale_reviews: true
        # Blocks merge until code owners have reviewed.
        require_code_owner_reviews: true
        # Specify which users and teams can dismiss pull request reviews. Pass an empty dismissal_restrictions object to disable. User and team dismissal_restrictions are only available for organization-owned repositories. Omit this parameter for personal repositories.
        dismissal_restrictions:
          users: []
          teams: []
      # Required. Require status checks to pass before merging. Set to null to disable
      required_status_checks:
        # Required. Require branches to be up to date before merging.
        strict: true
        # Required. The list of status checks to require in order to merge into this branch
        contexts: ['Build & Test']
      # Required. Enforce all configured restrictions for administrators. Set to true to enforce required status checks for repository administrators. Set to null to disable.
      enforce_admins: null
      # Prevent merge commits from being pushed to matching branches
      required_linear_history: null
      # Required. Restrict who can push to this branch. Team and user restrictions are only available for organization-owned repositories. Set to null to disable.
      restrictions: null
  - name: main
    # https://docs.github.com/en/rest/reference/repos#update-branch-protection
    # Branch Protection settings. Set to null to disable
    protection:
      # Required. Require at least one approving review on a pull request, before merging. Set to null to disable.
      required_pull_request_reviews:
        # The number of approvals required. (1-6)
        required_approving_review_count: 1
        # Dismiss approved reviews automatically when a new commit is pushed.
        dismiss_stale_reviews: true
        # Blocks merge until code owners have reviewed.
        require_code_owner_reviews: true
        # Specify which users and teams can dismiss pull request reviews. Pass an empty dismissal_restrictions object to disable. User and team dismissal_restrictions are only available for organization-owned repositories. Omit this parameter for personal repositories.
        dismissal_restrictions:
          users: []
          teams: []
      # Required. Require status checks to pass before merging. Set to null to disable
      required_status_checks:
        # Required. Require branches to be up to date before merging.
        strict: true
        # Required. The list of status checks to require in order to merge into this branch
        contexts: ['Build & Test']
      # Required. Enforce all configured restrictions for administrators. Set to true to enforce required status checks for repository administrators. Set to null to disable.
      enforce_admins: null
      # Prevent merge commits from being pushed to matching branches
      required_linear_history: null
      # Required. Restrict who can push to this branch. Team and user restrictions are only available for organization-owned repositories. Set to null to disable.
      restrictions: null

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 35
  • Comments: 47 (7 by maintainers)

Commits related to this issue

Most upvoted comments

I am also having this issue with branch protection rules not being applied. I modified the settings.yml many times, checked the app installation many times and it is just not working.

since the issue is open for a long time without any progress and following https://github.blog/2023-07-24-github-repository-rules-are-now-generally-available/, it seems that settings app is losing relevance 😦

from a quick look, rest api for ruleset is available. let’s revive this amazing app!

Is there a way to test a settings file? Like a github-action which parses the config in the same way as the probot-settings app.

Hey everyone! I’ve been having this issue for the past couple of hours and it’s driving me crazy so I decided to run my own instance to be able to look at logs:

Aside from the already mentioned problems other users suggested like @kmgrime or @benjyiw my problem was fixed after removing the dismissal_restrictions property.

As you can see in the logs:

Validation Failed: "Only organization repositories can have users and team restrictions"

There might be other properties affecting your settings.yml file related to this so be sure to take a good look.

I will finally suggest to run your own instance of the bot as it helps a lot finding the particual issue in your file. There is a good guide in the Docs deploying guide

image

guys, is settings app dead?

looks like…

any updates about this issue? it is a blocker on my way right now in using probot in all the repos in my organization. @travi sorry for mentioning you but I really want to know the status of this issue since it has been almost a month.

Thanks!

We had similar issues where the settings were working and then one day they stopped working for certain repos. After attempting many of the fixes suggested above, we were able to resolve our issue by omitting the enable_automated_security_fixes property. Whether we enable or disable, just having this property present seems to cause an issue. Looking at our other repos that the settings were still being applied for, the enable_automated_security_fixes was not in the settings file and thus the protections were still being applied. All other properties seem to be working fine for us including the enable_vulnerability_alerts which seems strange to me since they use similar logic in the code.

Thank you mate, Tried to remove enable_automated_security_fixes

Still not working for me šŸ˜•

Is there a real fix for it?

I’ve tried all the things that people here mentioned… but nothing works, Branch protection is not created.

Here is one that I’ve tried

https://github.com/mrlesmithjr/ansible-nginx/blob/master/.github/settings.yml

@mrlesmithjr - If this is the file you are running you don’t have all the settings required in the file so it will not be parsed correctly. If you have settings that you don’t use in the file, leave them empty instead of removing them. There is multiple good settings files here that is complete that you can use as template from the answers in this thread, hopefully one of them could be a good starting point. Bottom line, all settings need to be in the file for it to work, even if you don’t need them - leave them blank.

Good luck šŸ‘

A working settings.yml that works for us: https://github.com/testcontainers/testcontainers-go/blob/main/.github/settings.yml

Hopefully it helps šŸ¤ž

Ran into this as well. Had a team with the org prefix in settings.yml and branch protection rules after that. Neither the team, nor branch protection settings were applied, until I commented out the teams section.

name: core <---- make sure it is the exact same name as it is in you github org and don’t include org name.

@travi how do we reference a team from another org? We have multiple orgs and would like to reference teams across them.

Got this to work after some debugging and a lot of testing we had to change or remove the following stuff.

  1. color: CC0000 <---- change this to ā€˜#CC0000’

  2. description: An issue with the system šŸ›. <---- remove the emoji

  3. name: core <---- make sure it is the exact same name as it is in you github org and don’t include org name. branches:

  4. name: master <---- change to main as main is GitHubs default and master is the old default

  5. #Dont change any properties under protection except values (true / false etc), it needs the properties to parse correctly it seems. Use the one in the readme for template but fix the values pointed out above

Example to show what protection properties I talk about

protection:
      # Required. Require at least one approving review on a pull request, before merging. Set to null to disable.
      required_pull_request_reviews:
        # The number of approvals required. (1-6)
        required_approving_review_count: 1
        # Dismiss approved reviews automatically when a new commit is pushed.
        dismiss_stale_reviews: true
        # Blocks merge until code owners have reviewed.
        require_code_owner_reviews: true
        # Specify which users and teams can dismiss pull request reviews. Pass an empty dismissal_restrictions object to disable. User and team dismissal_restrictions are only available for organization-owned repositories. Omit this parameter for personal repositories.
        dismissal_restrictions:
          users: []
          teams: []
      # Required. Require status checks to pass before merging. Set to null to disable
      required_status_checks:
        # Required. Require branches to be up to date before merging.
        strict: true
        # Required. The list of status checks to require in order to merge into this branch
        contexts: []
      # Required. Enforce all configured restrictions for administrators. Set to true to enforce required status checks for repository administrators. Set to null to disable.
      enforce_admins: true
      # Prevent merge commits from being pushed to matching branches
      required_linear_history: true
      # Required. Restrict who can push to this branch. Team and user restrictions are only available for organization-owned repositories. Set to null to disable.
      restrictions:
        apps: []
        users: []
        teams: []

FWIW, I was able to fix the branch protection problem in my case by adjusting the default labels. I was using the label configuration exactly as is from the README from this project. This sounds pretty silly, but I tried removing the caterpillar emoji, and it seemed to have fixed the problem in my repos.

Orig from README:

labels:
  - name: bug
    color: CC0000
    description: An issue with the system šŸ›.

And now:

labels:
  - name: bug
    color: CC0000
    description: An issue with the system.

Additionally, in my case I already had all of the security settings enabled, which others mentioned was the culprit for their problems. So that didn’t seem to be causing an issue for me. Hope this information is helpful to others.

after a painful hour of debugging, I found the problematic line. the enable_automated_security_fixes: false line which is also present on the README but set to true has caused probot settings to fail processing at some point and eventually causing branch protection rules to fail. I am happy to say that removing that line fixed branch protection problems in all my repositories!

Is there a way to test a settings file? Like a github-action which parses the config in the same way as the probot-settings app.

there isn’t currently, but it certainly could be valuable. a big part of the complexity with this is that most of the details to verify are not defined by the settings app, but rather by the APIs called by the settings app, which can change independently from the maintenance that happens within this app.

if something along these lines were to be implemented, it would need to automatically account for the expectations of the APIs. currently, i believe implementing #518 would provide better ROI, so i am prioritizing that over a file validator. i’m open to input if folks have ideas around solving the latter, though.