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
- ci(branches): testing config from settings issue https://github.com/repository-settings/app/issues/625#issuecomment-1251943354 — committed to travi-test/settings-test by travi 2 years ago
- fix: disable security fixes See https://github.com/repository-settings/app/issues/625#issuecomment-1252623857 — committed to tc-experiments/.github by mdelapenya 2 years ago
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_restrictionsproperty.As you can see in the logs:
There might be other properties affecting your
settings.ymlfile 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
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!
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.
@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.ymlthat works for us: https://github.com/testcontainers/testcontainers-go/blob/main/.github/settings.ymlHopefully 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
teamssection.@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.
color: CC0000 <---- change this to ā#CC0000ā
description: An issue with the system š. <---- remove the emoji
name: core <---- make sure it is the exact same name as it is in you github org and donāt include org name. branches:
name: master <---- change to main as main is GitHubs default and master is the old default
#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
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:
And now:
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: falseline 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!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.