Configure GitHub

The generated templates make some assumptions about how the GitHub repository is configured. Here is a summary of changes you should do to the repository to make sure everything works as expected.

Issues

Labels

Review the list of labels and add:

• part:xxx labels that make sense to the project

• Make sure there is a cmd:skip-release-notes label, and if there isn't, create one with 930F79 as color and the following description:

  It is not necessary to update release notes for this PR

• All labels used by automation in the project, for example look for labels listed in:

  • .github/keylabeler.yml
  • .github/labeler.yml
  • .github/dependabot.yml
  • .github/workflows/release-notes-check.yml

Discussions

This depends on the repo, but in general we want this:

• Remove the Show and tell and Poll categories

• Rename the Q&A category to Support and change the emoji to :sos:

This one is important to match the link provided in .github/ISSUE_TEMPLATE/config.yml.

Settings

General

Default branch

• Rename to v0.x.x (this is required for the common CI to work properly when creating releases)

Features

• Wikis
• Issues
• Sponsorships
• Projects
• Preserve this repository
• Discussions

Pull Requests

• Allow merge commits: Default to pull request title and description
• Allow squash merging
• Allow rebase merging
• Always suggest updating pull request branches
• Allow auto-merge
• Automatically delete head branches

Archives

• Include Git LFS objects in archives

Pushes

• Limit how many branches and tags can be updated in a single push: 5

Collaborators and teams

• Give the team owning the repository Role: Admin
• Give everybody team Role: Triage

Branches

After importing code to the repository, add the following Branch protection rules (as always this is a guideline, defaults that should be used unless there is a reason to diverge):

Protect matching branches

Note

This is only to enable the merge queue, all the real protection rules will be added afterwards via rulesets. This is why all other protections are disabled here.

Add a rule for the main branch (v0.x.x) without wildcards so merge queues can be enabled:

• Require a pull request before merging
  • Require approvals: 1
  • Dismiss stale pull request approvals when new commits are pushed
  • Require review from Code Owners
  • Restrict who can dismiss pull request reviews
  • Allow specified actors to bypass required pull requests
  • Require approval of the most recent reviewable push
• Require status checks to pass before merging
  • Require branches to be up to date before merging
  • (add all the tests that should pass)
• Require conversation resolution before merging
• Require signed commits
• Require linear history
• Require merge queue:
  • Maximum pull requests to build: 5
  • Minimum pull requests to merge: 2 (this should be the only change to defaults) or after 5 minutes
  • Maximum pull requests to merge: 5
  • Only merge non-failing pull requests
  • Consider check failed after 60
• Require deployments to succeed before merging
• Lock branch
• Do not allow bypassing the above settings
• Restrict who can push to matching branches (this might be disabled while pushing the initial changes)
• Rules applied to everyone including administrators
  • Allow force pushes
  • Allow deletions

Rules

Rulesets

Import the following rulesets:

Note

You might need to adapt the status checks in the Protect version branches ruleset depending on your repository configuration.

• Disable creation of non-release tags
• Disable creation of other branches
• Disallow removal and force-pushes of gh-pages
• Protect released tags
• Protect version branches

Code security and analysis

• Enable Dependabot version updates if relevant

Code

The basic code configuration should be generate using repo-config.

GitHub Pages

No special configuration is needed for GitHub Pages, but you need to initialize the gh-pages branch. You can read how to do this in the Initialize GitHub Pages section.