ci(settings): added initial settings that should be applied consistently across the org #9
Conversation
…tly across the org
… directory especially for the `settings.yml` since it has the ability to modify the admin settings of the repository
travi
changed the title
|
i enabled the settings app for all repos in the org, so this will be applied to this repo upon merging and available for extension from the others |
| has_projects: false | ||
| allow_squash_merge: true | ||
| allow_merge_commit: false | ||
| allow_rebase_merge: false |
| @@ -0,0 +1 @@ | |||
| /.github/** @semantic-release/maintainers | |||
| dismissal_restrictions: null | ||
| required_status_checks: | ||
| strict: false | ||
| contexts: ['test', 'WIP'] |
There was a problem hiding this comment.
should we also add branch protection for the pre- and maintenance releases?
nextbeta*.x
There was a problem hiding this comment.
unfortunately, i believe the api is limited from setting up protection on branches that dont exist. i just confirmed with travi-test/settings-test@17cba6c that its not working. if you happen to have insight to suggest this should work, I would love to be able to support this.
do we currently define this type of protection? the other thing to consider, if so is that it might get removed if we dont define it
There was a problem hiding this comment.
dug a little deeper to at least confirm that the current issue is a 404 result with message "Branch not found" for
method: "PUT"
url: "https://api.github.com/repos/travi-test/settings-test/branches/alpha/protection"
There was a problem hiding this comment.
it looks like we at least wont remove existing protection rules when not defined in the file
There was a problem hiding this comment.
good to know, I thought I had branch protection for all release branches implemented before, but I only created the issue as a reminder. Thanks for looking into this.
All good then, let's ship!
There was a problem hiding this comment.
looking back through settings issues, i did find this mention that it should work: repository-settings/app#136 (comment). my tests, even last night, through octokit rest suggest otherwise, but i havent dug much deeper than our current implementation and the octokit rest docs.
i dont find a mention of createBranchProtectionRule directly in the octokit docs, so i would have to follow up to better understand. are you familiar with an approach other than what is currently happening to adjust with octokit rest? i'm also open to going down the graphql route, but not sure where to start without some digging.
|
|
||
| teams: | ||
| - name: maintainers | ||
| permission: maintain |
for #7
i think this could be merged as is, but it does have a few gaps that we will probably want to close with follow up changes:
maintainersteam. i still wonder if there would be value in an admins or owners team, or maybe a triage or contributors team that we could define other permission levels for. then we could add other members to those teams in the future and have the permissions already granted. we can discuss and update later if we decide to add anything like that