Open QuintinWillison opened 3 years ago
Looking at the starting set in my opening comment, I think there are probably a few logical groupings of checks here:
hasIssuesEnabled
: true
GitHub UI: 'Issues'
'Issues integrate lightweight task tracking into your repository. Keep projects on track with issue labels and milestones, and reference them in commit messages.'hasProjectsEnabled
: false
GitHub UI: 'Projects'
Should be disabled at org-level, but still correct to check at repository-level.hasWikiEnabled
: false
GitHub UI: 'Wikis'forkingAllowed
: true
if public, false
if private
'Allow forking' (only displays in options for private repositories)deleteBranchOnMerge
: true
GitHub UI: 'Automatically delete head branches'rebaseMergeAllowed
: false
GitHub UI: 'Allow rebase merging'
'Add all commits from the head branch onto the base branch individually.'squashMergeAllowed
: false
GitHub UI: 'Allow squash merging'
'Combine all commits from the head branch into a single commit in the base branch.'mergeCommitAllowed
: true
GitHub UI: 'Allow merge commits'
'Add all commits from the head branch to the base branch with a merge commit.'autoMergeAllowed
(boolean
)isArchived
: false
isDisabled
: false
isLocked
: false
Regarding isBlankIssuesEnabled
, see this GitHub blog post. This doesn't quite mean what it's easy to assume it means. Needs more thought as, thus far - at least for open source repositories - we've remained pretty unopinionated about issue templates.
The things that should:
Taking a quick look using GitHub's GraphQL API Explorer, this query represents a good starting set:
In the example above I've intentionally set
first
to10
andprivacy
toPUBLIC
, for illustrative purposes, so I can feel free to share the result: