|
| 1 | +- Use `cargo fmt`. Always perform `make lint clippy` before publishing when code is changed. |
| 2 | + - Use an extra binding if this saves more than one (formatted) LOC, e.g. |
| 3 | +```rust |
| 4 | +let svc = ATTESTATION_KEY_REGISTER_SERVICE; |
| 5 | +self.create_certificate(svc, ATT_REG_CERT, ATT_REG_SECRET, issuer_name) |
| 6 | + .await?; |
| 7 | +``` |
| 8 | +over |
| 9 | +```rust |
| 10 | +self.create_certificate( |
| 11 | + ATTESTATION_KEY_REGISTER_SERVICE, |
| 12 | + ATT_REG_CERT, |
| 13 | + ATT_REG_SECRET, |
| 14 | + issuer_name, |
| 15 | +) |
| 16 | +.await?; |
| 17 | +``` |
| 18 | +- Use [REUSE](https://reuse.software) comments for new files, or exclude in [REUSE.toml](./REUSE.toml) when not possible. |
| 19 | +- Follow [k8s API conventions](https://github.com/kubernetes/community/blob/main/contributors/devel/sig-architecture/api-conventions.md) |
| 20 | + - Use [reflector-backed caches](https://github.com/trusted-execution-clusters/operator/pull/267) where possible |
| 21 | +- Add design documents for large features |
| 22 | +- When functionality is changed, perform `make test`, and [integration test](./tests/README.md) at least with basic attestation. |
| 23 | +- Test with the infrastructure a test needs -- unit with mocked API server, cluster test with a cluster, and attestation test with VMs. Preferably, add a test when |
| 24 | + - adding a feature |
| 25 | + - fixing a bug, with a test that you verify isolates this bug |
| 26 | +- For members |
| 27 | + - Set membership to public so GHA runs integration tests without requiring the ok-to-test label |
| 28 | + - Merge when you have approval, passing tests, and are happy with your PR. |
| 29 | + |
| 30 | +# Committing |
| 31 | + |
| 32 | +- [Sign commits cryptographically](https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---gpg-signkey-id) |
| 33 | +- Limit commit subjects to 50 and messages to 72 characters. Leave an empty line between subject and message. |
| 34 | +- Add small changes to larger PRs in separate commits to ease review burden, but do not add them to already open PRs |
| 35 | +- Commit subjects |
| 36 | + - Prepend your commit subject with a short focus area. Omit this when making general operator changes. Examples are `tests`, `tests/azure`, `rvs` (reference values) |
| 37 | + - Most subjects should start with a verb in infinitive form, e.g. `Add reference value removal test` |
| 38 | +- Explain what you did, and why you did it when it isn't obvious |
| 39 | +- Commit trailers |
| 40 | + - [Sign off commits](https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---signoff) |
| 41 | + - Do not mark AI use in the commit trailer, but do mark it in the PR description. |
| 42 | +- Put separate changes in separate commits, but bisects should stay intact |
| 43 | + - Linting should pass, so a new definition must be used in the same commit. |
| 44 | + - When a change requires a change to a test, the changes should be in the same commit. On the contrary, a larger new test can be in a separate commit for easier review. |
| 45 | + |
| 46 | +# AI use |
| 47 | + |
| 48 | +- Do not raise PRs that you do not understand. Review changes with your own eyes before raising. |
| 49 | +- Do not respond to review inquiries with replies that you do not understand |
| 50 | +- Nontrivial use of AI for a PR must be included in the PR description, e.g. "This PR was written in part with the assistance of generative AI". Feel free to also include what you used AI for, however, prompts and model used are not expected due to AI's nondeterminism. |
0 commit comments