|
1 | | - # Codex Assistant Guidance |
| 1 | +# Codex Assistant Guidance |
2 | 2 |
|
3 | | - This document provides recommended steps for the OpenAI Codex assistant when making changes to the `cmdy` repository. |
| 3 | +This document provides recommended steps for the OpenAI Codex assistant when making changes to the `cmdy` repository. |
4 | 4 |
|
5 | | - ## Workflow |
| 5 | +## Workflow |
6 | 6 |
|
7 | | - 1. After applying code changes or patches, run: |
8 | | - ```sh |
9 | | - cargo check |
10 | | - cargo fix --allow-dirty |
11 | | - ``` |
12 | | - - `cargo check` verifies that the code compiles without errors. |
13 | | - - `cargo fix --allow-dirty` applies automatic fixes (e.g., unused imports) and allows minor edits to your working directory. |
| 7 | +1. After applying code changes or patches, run: |
| 8 | + ```sh |
| 9 | + cargo check |
| 10 | + cargo fix --allow-dirty |
| 11 | + cargo fmt |
| 12 | + cargo clippy -- -D warnings |
| 13 | + ``` |
| 14 | + - `cargo check` verifies that the code compiles without errors. |
| 15 | + - `cargo fix --allow-dirty` applies automatic fixes (e.g., unused imports) and allows minor edits to your working directory. |
| 16 | + - `cargo fmt` ensures consistent code formatting. |
| 17 | + - `cargo clippy -- -D warnings` checks for common mistakes and ensures no clippy warnings. |
14 | 18 |
|
15 | | - 2. Verify functionality and ensure all tests pass: |
16 | | - ```sh |
17 | | - cargo test |
18 | | - ``` |
| 19 | +2. Verify functionality and ensure all tests pass: |
| 20 | + ```sh |
| 21 | + cargo test # Unit tests |
| 22 | + cargo test --test integration # Integration tests |
| 23 | + ``` |
19 | 24 |
|
20 | | - ## Best Practices |
| 25 | +3. Before pushing changes, run the pre-push checks: |
| 26 | + ```sh |
| 27 | + ./scripts/pushable |
| 28 | + ``` |
21 | 29 |
|
22 | | - - Keep changes minimal and focused on the user’s request. |
23 | | - - Maintain coding style consistent with the existing codebase. |
24 | | - - Use `git status` to review uncommitted changes before concluding a task. |
25 | | - - Do not add unrelated modifications or fix pre-existing issues outside of the described task scope. |
26 | | - - Only add code comments when they explain something unusual or complex. Do not narrate all the code. |
| 30 | +## Handling Dependabot PRs |
| 31 | + |
| 32 | +When processing dependabot pull requests: |
| 33 | + |
| 34 | +1. Check all open dependabot PRs: |
| 35 | + ```sh |
| 36 | + gh pr list --author "app/dependabot" --state open |
| 37 | + ``` |
| 38 | + |
| 39 | +2. For each PR, checkout and run validation: |
| 40 | + ```sh |
| 41 | + gh pr checkout <PR_NUMBER> |
| 42 | + ./scripts/pushable |
| 43 | + ``` |
| 44 | + |
| 45 | +3. Common issues and fixes: |
| 46 | + - **Clippy warnings**: Fix any `map().unwrap_or_else()` warnings by replacing with `map_or_else()` |
| 47 | + - **Integration test failures**: Ensure the program handles edge cases gracefully (e.g., missing directories should exit with code 0) |
| 48 | + - **Merge conflicts**: After merging one PR, rebase others on main to resolve conflicts |
| 49 | + |
| 50 | +4. If fixes are needed: |
| 51 | + ```sh |
| 52 | + # Make necessary fixes |
| 53 | + cargo fmt |
| 54 | + git add -A |
| 55 | + git commit -m "fix: <description of fix>" |
| 56 | + git push |
| 57 | + ``` |
| 58 | + |
| 59 | +## Creating Releases |
| 60 | + |
| 61 | +The project uses `cargo-release` for version management. Follow these steps: |
| 62 | + |
| 63 | +1. Ensure all tests pass and CI is green: |
| 64 | + ```sh |
| 65 | + cargo test |
| 66 | + ./scripts/pushable |
| 67 | + ``` |
| 68 | + |
| 69 | +2. Determine version bump type: |
| 70 | + - **patch** (0.1.5 → 0.1.6): Bug fixes, dependency updates |
| 71 | + - **minor** (0.1.5 → 0.2.0): New features, backward-compatible changes |
| 72 | + - **major** (0.1.5 → 1.0.0): Breaking changes |
| 73 | + |
| 74 | +3. Create the release: |
| 75 | + ```sh |
| 76 | + # For patch release (most common) |
| 77 | + cargo release patch --no-publish --execute |
| 78 | + |
| 79 | + # For minor release |
| 80 | + cargo release minor --no-publish --execute |
| 81 | + |
| 82 | + # For major release |
| 83 | + cargo release major --no-publish --execute |
| 84 | + ``` |
| 85 | + |
| 86 | +4. The release process will: |
| 87 | + - Update version in Cargo.toml and Cargo.lock |
| 88 | + - Create a release commit: "chore: release X.Y.Z" |
| 89 | + - Create a git tag: "vX.Y.Z" |
| 90 | + - Push commit and tag to GitHub |
| 91 | + - Trigger GitHub Actions to publish to crates.io |
| 92 | + |
| 93 | +5. If a release fails CI, rollback and retry: |
| 94 | + ```sh |
| 95 | + # Delete the tag locally and remotely |
| 96 | + git tag -d v0.1.X |
| 97 | + git push origin :v0.1.X |
| 98 | + |
| 99 | + # Fix the issue, then re-release |
| 100 | + cargo release patch --no-publish --execute |
| 101 | + ``` |
| 102 | + |
| 103 | +## Best Practices |
| 104 | + |
| 105 | +- Keep changes minimal and focused on the user's request. |
| 106 | +- Maintain coding style consistent with the existing codebase. |
| 107 | +- Use `git status` to review uncommitted changes before concluding a task. |
| 108 | +- Do not add unrelated modifications or fix pre-existing issues outside of the described task scope. |
| 109 | +- Only add code comments when they explain something unusual or complex. Do not narrate all the code. |
| 110 | +- Always run `cargo fmt` before committing to ensure consistent formatting. |
| 111 | +- Ensure CI passes before merging any changes. |
27 | 112 |
|
0 commit comments