|
| 1 | +# Steeltoe Build and Test Guide for Developers and CI/CD Agents |
| 2 | + |
| 3 | +This document provides essential guidelines for working with the Steeltoe codebase. For detailed build and test procedures, refer to the [GitHub workflows](.github/workflows/) which serve as the source of truth. |
| 4 | + |
| 5 | +## General Guidelines |
| 6 | + |
| 7 | +### Code Review and Suggestions |
| 8 | +- Only make high confidence suggestions when reviewing code changes. |
| 9 | +- Always use the latest stable version of C#. |
| 10 | +- Never add or change `global.json` unless explicitly asked to. |
| 11 | +- Never change `NuGet.config` files unless explicitly asked to. |
| 12 | + |
| 13 | +### Null Handling |
| 14 | +- Declare variables non-nullable, and check for null at public API entry points. |
| 15 | +- For internal code, trust the C# null annotations and don't add null checks when the type system says a value cannot be null. |
| 16 | + |
| 17 | +### Writing Tests |
| 18 | +- Do not emit "Act", "Arrange" or "Assert" comments in test code. |
| 19 | +- Tests should pass before committing and pushing changes. |
| 20 | +- When possible, code coverage levels should be increased or at least maintained. |
| 21 | + |
| 22 | +## Prerequisites |
| 23 | + |
| 24 | +- **.NET SDK 10.0** (latest patch version) |
| 25 | +- **.NET Runtime 8.0** (latest patch version) |
| 26 | +- **.NET Runtime 9.0** (latest patch version) |
| 27 | + |
| 28 | +Verify your installation: |
| 29 | +```bash |
| 30 | +dotnet --list-sdks |
| 31 | +dotnet --list-runtimes |
| 32 | +``` |
| 33 | + |
| 34 | +## Quick Start |
| 35 | + |
| 36 | +For quick iteration during development: |
| 37 | +```bash |
| 38 | +dotnet build |
| 39 | +dotnet test |
| 40 | +``` |
| 41 | + |
| 42 | +For final validation before committing changes: |
| 43 | +```bash |
| 44 | +dotnet build src/Steeltoe.All.sln --configuration Release |
| 45 | +dotnet test src/Steeltoe.All.sln --configuration Release |
| 46 | +``` |
| 47 | + |
| 48 | +### Run Tests |
| 49 | + |
| 50 | +For detailed test procedures including environment-specific filters, test categories, and coverage collection, see [`.github/workflows/Steeltoe.All.yml`](.github/workflows/Steeltoe.All.yml). |
| 51 | + |
| 52 | +**Important context for agents:** |
| 53 | +- Tests run on multiple frameworks: net8.0, net9.0, and net10.0 |
| 54 | +- Tests use xUnit trait categories: `Integration` (requires Docker services), `MemoryDumps` (generates memory dumps) |
| 55 | +- Platform-specific test skipping uses attributes like `[FactSkippedOnPlatform]` and `[TheorySkippedOnPlatform]` instead of trait categories |
| 56 | +- Integration tests require Docker containers to be running (e.g., Config Server, Eureka Server) and are primarily designed for Linux CI environments |
| 57 | +- When writing tests, use `[Trait("Category", "Integration")]` for tests requiring external services like Docker containers |
| 58 | + |
| 59 | +## Code Style Validation |
| 60 | + |
| 61 | +Steeltoe uses ReSharper/Rider code cleanup tools via `regitlint` to enforce consistent code style. The CI workflow (`.github/workflows/verify-code-style.yml`) automatically verifies code style on all pull requests. |
| 62 | + |
| 63 | +To run code cleanup locally: |
| 64 | +```powershell |
| 65 | +./cleanupcode.ps1 main |
| 66 | +``` |
| 67 | + |
| 68 | +If your PR fails the code style check, run `cleanupcode.ps1` locally and commit the changes. |
| 69 | + |
| 70 | +## Additional Resources |
| 71 | + |
| 72 | +- [Steeltoe Documentation](https://steeltoe.io/) |
| 73 | +- [Contributing Guidelines](https://github.com/SteeltoeOSS/Steeltoe/wiki) |
| 74 | +- [CI Workflow](.github/workflows/Steeltoe.All.yml) |
| 75 | +- [Code Style Workflow](.github/workflows/verify-code-style.yml) |
0 commit comments