|
| 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 | + - Mark AI use in the commit trailer, such as `Assisted-by: AI` |
| 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 must be included in the commit message trailer |
0 commit comments