Repositories

Guide to creating and managing Q-CTRL repositories


Source code created at Q-CTRL is managed using Git repositories. Q-CTRL uses GitHub to host these repositories.

Types of repositories

The type of repository created defines the default configurations that are set as well as some of the naming conventions. There are two types of repositories:

  1. Standard repositories
  2. Research repositories

Standard repositories

Standard repositories are the default repository type, and they usually contain source code that directly contributes to Q-CTRL’s products. This can refer (but is not limited) to:

  • Applications
  • Configurations
  • Documentation
  • Infrastructure
  • Software

Standard repositories have strict requirements regarding access control as well as configurations to ensure a higher standard of code quality.

Research repositories

Research repositories have less strict configurations than standard repositories and are usually used for research purposes (including spikes). As research repositories are held to a lower standard, they cannot contain source code that directly contributes to Q-CTRL’s products. A research repository MUST be correctly configured before it can become a standard repository. It is also prohibited from using any CI/CD tooling.

Naming repositories

Refer to repository naming conventions.

Repository descriptions

Repository descriptions MUST take the form <emoji> <project name> (see project naming conventions).

Examples

Project Repository description
Q-CTRL Open Controls 🎛 Q-CTRL Open Controls
Q-CTRL Template 🧩 Q-CTRL Template

Ownership of repositories

All repositories MUST have at least one owner. An owner MUST be a team and not an individual person. Teams are defined by Q-CTRL’s organization structure.

A repository MAY have more than one owner and ownership of the repository can refer to:

  • All code in the repository.
  • A folder.
  • A file.

For example, for a GraphQL project, the Back-end Engineering team may own the API code, the Front-end Engineering team may own the GraphQL schemas defined in a folder, and the Infrastructure team may own certain CI files.

Repository visibility

All repositories MUST be private unless there is a reason to make them public. Some reasons that a repository would be made public include:

  • The repository contains an open source project.
  • The repository needs to be publicly viewable by people outside of the Q-CTRL organization.
  • The repository is a fork of another public repository.

Creating, modifying, and archiving repositories

Repositories are controlled using the Q-CTRL Repositories Manager. This is in accordance with Q-CTRL’s Operations security policy and is integral to Q-CTRL’s ISO/IEC 27001 compliance.

IMPORTANT: Any repositories created outside of the Q-CTRL Repositories Manager will be automatically and permanently deleted. This action is not reversible.

Creating and modifying repositories

See creating or modifying a repository.

Archiving repositories

See archiving a repository.

Configuration

All repositories MUST use the common configuration. If the repository is a standard repository, then it MUST also use the standard repository configuration.

Common configuration

Configuration Description
Automatically delete merging branch This is to avoid stale branches. Restore the branch if more contributions are needed.
Issues disabled for private repositories Use Jira to create issues. Issues are to be used for public facing issues only.
Master branch protection The master branch is protected and no commits can be pushed to it without a pull request.
Require pull requests to be approved by an owner An owner must approve a pull request before it can be merged.
Squash merges only All other merge types are disabled. See contributing.
Wiki is disabled Use instead the appropriate type of documentation listed in the documentation standards.

Standard repository configuration

Configuration Description
Dismiss stale reviews Dismissing stale reviews will require an owner to approve a pull request if any changes have been done since their last review. This is in place to avoid the situation where a pull request is approved, then a change is introduced that would have not been approved but was merged anyway.
Require up-to-date pull requests for merging Pull requests must be up to date with master branch before merging is enabled. This is to ensure that pull requests are tested with the latest changes.