| name | code-review |
| description | Repo-specific guidance for reviewing pull requests on hifiberry-os. Use this whenever reviewing a pull request or diff in this repository. |
hifiberry-os is a collection of Debian packages plus the scripts that build,
check, and publish them. Most changes fall into one of: a package under
packages/<name>/, a top-level shell script, or CI/tooling. Review with that
in mind rather than as a generic application codebase.
Packages tree (packages/*)
Every package pulls its sources either as a git submodule or via a clone made
by its own build.sh — never both for the same path. When a diff touches a
package, check for the failure modes scripts/check-packages.py is designed
to catch:
- A submodule added to the tree but missing from
.gitmodules.
- A path that is simultaneously a submodule and a
build.sh clone target.
- A
build.sh clone target that isn't covered by .gitignore — this is one
git add . away from committing a whole upstream source tree.
- A package version in
debian/changelog that doesn't match the version in
the package's own manifest (e.g. setup.py, package.json, Cargo.toml).
If the PR run of the packages consistency workflow
(.github/workflows/check-packages.yml, runs check-packages.py) is
available via the GitHub MCP server, check its result rather than
re-deriving these checks by hand.
Shell scripts
Top-level scripts (addrepo, install-all, upgrade-to-trixie,
packages/*/build.sh, etc.) are curl-piped-to-bash or run unattended on
embedded devices. Flag:
- Missing
set -e (or equivalent) where a failed step should abort instead
of continuing silently.
- Unquoted variable expansions that break on paths with spaces.
- Destructive commands (
rm -rf, package purges, partition/flash operations)
that aren't guarded or don't fail loudly.
Secrets and publishing
Nothing in this repo should reference private hostnames, IPs, credentials,
or tokens for the build/publish pipeline (aptly, the debianrepo host, SSH
keys). If a diff adds any, flag it regardless of how it's framed.
Scope
Keep review comments proportional to the diff: a .gitignore or docs-only
change doesn't need packaging/shell scrutiny, and a one-line version bump
doesn't need a design discussion.
