Skip to content

Add CODEOWNERS file for predictable review routing #90

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
laurentketterle-hub wants to merge 3 commits into from
Closed

Add CODEOWNERS file for predictable review routing #90

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
be47fbb
Add CODEOWNERS file for predictable review routing
laurentketterle-hub Aug 5, 2026
303d472
fix: disable Vercel deployment on fork (no token)
laurentketterle-hub Aug 6, 2026
fd20d23
docs: add CI/CD pipeline overview and PR review checklist to CONTRIBU…
laurentketterle-hub Aug 7, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 15 additions & 0 deletions .github/CODEOWNERS
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
# Default owners for everything in the repo
* @Flamki

# Documentation
*.md @Flamki
docs/ @Flamki

# Source code
src/ @Flamki
public/ @Flamki

# CI/CD and configuration
.github/ @Flamki
package.json @Flamki
eslint.config.js @Flamki
34 changes: 34 additions & 0 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -199,3 +199,37 @@ git commit --no-verify -m "your message"

Use `--no-verify` sparingly. It disables **all** hooks. Document why you bypassed in the PR
description so reviewers are aware.

## Code Ownership

This repository uses a [CODEOWNERS](.github/CODEOWNERS) file to automatically request reviews
from the appropriate maintainers when pull requests are opened. The ownership is organized as follows:

- **All files**: `@Flamki` — default owner for the entire repository
- **Documentation** (`*.md`, `docs/`): `@Flamki`
- **Source code** (`src/`, `public/`): `@Flamki`
- **CI/CD and configuration** (`.github/`, `package.json`, `eslint.config.js`): `@Flamki`

When you open a pull request, GitHub automatically assigns reviewers based on the paths you modified.
This ensures PRs are reviewed by the maintainers most familiar with the affected code.
Comment on lines +213 to +214

@coderabbitai coderabbitai Bot Aug 5, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "CONTIBUTING.md relevant lines:"
sed -n '200,220p' CONTRIBUTING.md | cat -n

echo
echo "CODEOWNERS contents:"
if [ -f .github/CODEOWNERS ]; then
  cat -n .github/CODEOWNERS
else
  echo ".github/CODEOWNERS not found"
fi

echo
echo "Search for CODEOWNER/codeowner references:"
rg -n -i "code.?own|reviewers|pr|pull request|approve|approval" CONTRIBUTING.md .github/CODEOWNERS 2>/dev/null || true

Repository: Flamki/stellarmind

Length of output: 3616

🌐 Web query:

GitHub CODEOWNERS requests reviews from matching owners does not guarantee review

💡 Result:

The presence of a CODEOWNERS file in a repository does not automatically guarantee that code owners must review or approve pull requests. By default, the CODEOWNERS feature simply automates the process of requesting reviews from the designated users or teams when a pull request modifies the files they own [1][2][3]. To enforce reviews from code owners, repository administrators must explicitly configure branch protection rules [1][3]. The behavior of this feature is as follows: 1. Automatic Requests: When a pull request is opened, GitHub automatically requests reviews from the specified code owners for the files changed [1][2]. This is a notification mechanism and does not block merging on its own [3]. 2. Enforcement through Branch Protection: If a repository is set up with a branch protection rule that includes "Require review from Code Owners," the merge process is blocked until at least one of the designated code owners for every changed file has approved the pull request [1][3]. 3. Approval Sufficiency: When branch protection is enabled, an approval from any one of the defined code owners for a specific file pattern is sufficient to satisfy the requirement [1][4]. It does not require approval from all listed owners [1]. Because the CODEOWNERS file is advisory by default, teams that rely on it for compliance or security without enabling the corresponding branch protection rule will find that pull requests can be merged without any code owner reviews [3]. Even with the rule enabled, a pull request can still be merged if other reviewers approve, provided that at least one valid code owner also approves [3].

Citations:

Avoid implying CODEOWNERS guarantees review or approval.

The contribution guidelines already say CODEOWNERS requests reviews from matching owners, so these lines should stop there or clarify that enforcement requires branch protection. As written, GitHub does not automatically assign reviewers, and the CODEOWNERS file alone can be treated as advisory when branch protection rules are not enabled.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@CONTRIBUTING.md` around lines 213 - 214, Update the CODEOWNERS guidance in
the pull request review section to state only that matching owners are requested
for review, or explicitly condition required review/approval on branch
protection settings. Remove the claim that GitHub automatically assigns
reviewers or that CODEOWNERS alone guarantees review.



## CI/CD Pipeline

Every pull request triggers automated lint, test, and secret-scan checks via GitHub Actions.
All three must pass before a PR can be merged. If a check fails, expand the job log
in the Checks tab on your PR for the full diagnostic output.

## PR Review Checklist

Before marking your pull request as ready for review, verify:

- Lint and format checks pass locally
- Tests pass
- No secrets or keys in the diff
- Issue reference in description (Closes #NN)
- Branch is up-to-date with upstream master
- New files follow the existing directory structure
- Commit messages use conventional commits format

Maintainers will use CODEOWNERS assignments to route your PR to the right reviewer automatically.
1 change: 1 addition & 0 deletions vercel.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
{"github": {"enabled": false, "silent": true}}

@coderabbitai coderabbitai Bot Aug 7, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🩺 Stability & Availability | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🌐 Web query:

Vercel vercel.json github enabled false deployments github.silent deprecated git configuration

💡 Result:

Yes, both the github.enabled and github.silent properties in vercel.json have been deprecated [1][2][3]. Here are the details regarding these changes: 1. github.enabled This property has been deprecated in favor of git.deploymentEnabled [4][1]. While github.enabled was previously used to prevent Vercel for GitHub from deploying a project, you should now use the git.deploymentEnabled configuration [1]. This newer property allows for more granular control, including the ability to use glob patterns to enable or disable automatic deployments for specific branches [5]. 2. github.silent This property was deprecated on September 25, 2023 [2][3]. It was previously used to prevent the Vercel bot from commenting on pull requests and commits [6][2]. It has been replaced by more fine-grained controls available directly in the Vercel dashboard [1][2]. You can manage these settings by navigating to your project's Settings, selecting the Git tab, and adjusting the comment preferences under the Connected Git Repository section [2][7]. If you previously had github.silent configured in your vercel.json, Vercel automatically adjusted your project settings to reflect that choice [8][7]. For managing these behaviors today, it is recommended to use the current git configuration schema in vercel.json for deployment triggers or the project dashboard for comment settings [1][2][9].

Citations:

🌐 Web query:

Vercel pull request fork protection settings approval required enabled

💡 Result:

Vercel provides a security feature known as Git Fork Protection, which requires authorization from you or a member of your Vercel team before a pull request from a fork of your repository can be deployed [1][2]. This feature is designed to protect your project from potential security risks, such as the unauthorized exfiltration of environment variables or the execution of malicious code within your build process [1][2][3]. Key details regarding this protection include: - How it works: If a pull request originating from a fork includes changes to the vercel.json file or if the project has environment variables configured, Vercel mandates manual authorization [4][3]. A link to authorize the deployment is automatically posted as a comment on the pull request [2]. - Management: You can enable or disable Git Fork Protection via the Security section of your Project Settings in the Vercel dashboard [1][5]. Additionally, as of April 2026, you can manage this setting through the Vercel CLI using project protection subcommands [6]. - Terraform: If you manage your infrastructure via Terraform, you can control this setting using the git_fork_protection boolean property in the vercel_project resource [4]. - Important Considerations: Vercel strongly advises that you review your environment variables and vercel.json configuration before choosing to disable this protection [1]. Please note that this is distinct from Code Approvers, a separate feature that allows you to define specific GitHub usernames or teams as required approvers for changes to certain directories or files within your codebase [7].

Citations:

🌐 Web query:

Vercel git.forkProtectionEnabled vercel.json vercel terraform disabled fork protection

💡 Result:

Git Fork Protection is a security feature on Vercel that requires authorization from a team member before deploying pull requests from forks if the project contains environment variables or changes to vercel.json [1][2][3]. You cannot disable Git Fork Protection using the vercel.json file [1][4]. Configuration for this feature is managed at the project level, not within the source repository's configuration file [1][3]. To disable Git Fork Protection: 1. Navigate to the Security section of your Project Settings in the Vercel Dashboard [1][3]. 2. Locate the Git Fork Protection setting and disable it [1][5]. 3. Note: Vercel advises that you should only disable this setting if you have reviewed your environment variables and vercel.json configuration to ensure no sensitive information is at risk [1][5]. When using Terraform, you can manage this setting via the vercel_project resource using the git_fork_protection argument [6][7]. Setting this to false in your Terraform configuration will disable the protection: resource "vercel_project" "example" { name = "example-project" git_fork_protection = false } The default value for this Terraform argument is true [6][7].

Citations:

🌐 Web query:

Vercel git commitStatus enabled silenced comments settings dashboard

💡 Result:

Vercel provides granular control over Git integration comments and commit statuses directly within the project settings on the Vercel dashboard [1][2]. Silence Comments You can manage Vercel's bot comments on your pull requests and commits by navigating to your project's Git settings [1][3]. 1. Navigate to your project on the Vercel Dashboard [1]. 2. Select the Settings tab and click on Git in the sidebar [1][4]. 3. Under the Connected Git Repository section, you can toggle specific switches to choose whether the Vercel bot comments on pull requests or production commits [1][2]. Note that the older method of using the github.silent property in vercel.json has been deprecated in favor of these dashboard settings [5][2]. Commit Status Settings By default, Vercel provides a GitHub Commit Status for every deployment, indicating if it succeeded, failed, or was skipped [1][4]. You can manage this in the same Git settings section [1]: - Consolidated Commit Status: For monorepos, you can enable a consolidated commit status [1][6]. This replaces the default behavior of creating one status per project with a single status on pull requests, reducing noise and simplifying branch protection configuration [6][4][7]. - Soft Failures: When using consolidated commit statuses, you can configure projects as soft failures so they do not block merges or fail the commit if they are temporarily failing to deploy [1][4]. These settings can be configured on a per-project basis, and Vercel also provides functionality to edit these Git settings across multiple projects within a repository simultaneously for easier management [8].

Citations:

Do not disable GitHub deployments to control fork authorization.

"github": {"enabled": false} disables all GitHub-triggered Vercel deployments, including trusted preview and production CI builds. Use Vercel Project Settings for Git Fork Protection when you only want to require approval for fork pull requests. Also remove github.silent: it is deprecated and controls Vercel bot comments, not silent deployment checks.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@vercel.json` at line 1, Update the Vercel configuration to remove the
github.enabled override and the deprecated github.silent setting, leaving
GitHub-triggered deployments enabled. Configure fork pull request authorization
through Vercel Project Settings using Git Fork Protection instead.

Loading