Skip to content

contributing.rst

Latest commit

 

History

History
91 lines (56 loc) · 3.09 KB

contributing.rst

File metadata and controls

91 lines (56 loc) · 3.09 KB
Raw

Contributing

Getting Started

  1. Fork the repository on GitHub
  2. Clone your fork and add the upstream remote:
git clone https://github.com/<your-username>/spur.git
cd spur
git remote add upstream https://github.com/ROCm/spur.git
  1. Follow the :doc:`building` guide to build the project and run tests. Get familiar with the build and test workflow before making changes.
  2. Before starting work, sync with upstream:
git fetch upstream
git rebase upstream/main

PR Title Format

PRs are squash-merged, so the PR title becomes the commit message on main. Use conventional commit format for your PR title: <type>(<scope>): <description>

type — one of: feat, fix, refactor, test, docs, style, perf, build, ci, chore, revert

scope — the crate name (e.g. spur-cli, spurctld, spur-core, spur-k8s). If no single crate applies, use a concise scope reflecting the area of change (proto, examples, config).

description — imperative mood, lowercase, no trailing period. Summarize the user-visible change, not the implementation detail.

Example:

feat(spur-k8s): add support for GPU resource limits in SpurJob spec

License Headers

All new source files (.rs, .proto, .py, .sh) must include this header at the top:

// Copyright (c) 2026 Advanced Micro Devices, Inc. All rights reserved.
// SPDX-License-Identifier: Apache-2.0

Use # instead of // for Python and shell scripts.

Pre-Commit Hooks

The repo includes pre-commit and commit-msg hooks that check formatting, license headers, and commit message format. Opt in by pointing git to the hooks directory:

git config core.hooksPath .githooks

This enforces:

  • cargo fmt --check --all — code formatting
  • SPDX license headers on staged source files
  • Commit message matches conventional commit format (see above)

If formatting fails, run cargo fmt --all and amend your commit. You can bypass hooks with git commit --no-verify, but CI will still enforce these checks.

PR Process

  1. Create a feature branch from main on your fork
  2. Make your changes in logical commits following the commit style above
  3. Ensure all pre-commit hook checks pass
  4. Push to your fork and open a PR against ROCm/spur:main

Note

All PRs must pass CI checks to be eligible for merging. If you see a CI test failing that doesn't look related to your changes, tag a maintainer in the PR for help.

Review Process

Maintainers look for clear code structure, adequate test coverage, and long-term maintainability. In particular:

  • New functionality has corresponding tests
  • Features are complete end-to-end within a single PR. Avoid partial implementations that leave unused code or require follow-up PRs to become functional
  • Commits are logically separated and follow the commit style
  • The PR description explains what changed and why