|
| 1 | +# Contributing |
| 2 | + |
| 3 | +Contributions are welcome from anyone, regardless of whether you are just starting your Python journey, a web developer or a seasoned Execution Layer developer! |
| 4 | + |
| 5 | +We appreciate your help and appreciate your contributions! |
| 6 | + |
| 7 | +## Code of Conduct |
| 8 | + |
| 9 | +All contributors are expected to be excellent to each other; other behavior is not tolerated. |
| 10 | + |
| 11 | +## Communication |
| 12 | + |
| 13 | +We encourage questions and discussions about the project. If you need help with the codebase or have questions about implementation details, please don't hesitate to reach out in the `#el-testing` channel in the [Ethereum R&D Discord Server](https://discord.com/invite/qGpsxSA). |
| 14 | + |
| 15 | +For detailed information on how to get help, please see the [Getting Help](https://eest.ethereum.org/main/getting_started/getting_help) page in our documentation, which includes communication channels and contact information for project maintainers. |
| 16 | + |
| 17 | +## Contributions We Welcome |
| 18 | + |
| 19 | +As mentioned in the README's [Contributing section](https://github.com/ethereum/execution-spec-tests#contributing), we welcome earnest contributions that have reasonable substance or resolve existing repository issues. |
| 20 | + |
| 21 | +## Contributions We Don't Accept |
| 22 | + |
| 23 | +We do not accept: |
| 24 | + |
| 25 | +- Contributions that only fix spelling or grammatical errors in documentation, code, or elsewhere. |
| 26 | +- Drive-by or vibe code contributions without proper engagement or context. |
| 27 | +- Pull requests from airdrop farmers. |
| 28 | + |
| 29 | +I.e., pull requests should have reasonable substance and context. |
| 30 | + |
| 31 | +## Reporting Bugs |
| 32 | + |
| 33 | +We use GitHub Issues to track bugs. To report a bug, please follow these guidelines: |
| 34 | + |
| 35 | +### Before Reporting |
| 36 | + |
| 37 | +1. **Check existing issues**: Search [open issues](https://github.com/ethereum/execution-spec-tests/issues) to see if your problem has already been reported. |
| 38 | +2. **Try to reproduce**: Confirm you can reproduce the issue consistently. |
| 39 | +3. **Consider security implications**: For security vulnerabilities, please do NOT create a public issue (or PR). Instead, refer to our [Security Policy](SECURITY.md) for responsible disclosure guidelines. |
| 40 | + |
| 41 | +### Creating a Bug Report |
| 42 | + |
| 43 | +When creating a new issue: |
| 44 | + |
| 45 | +1. **Use a clear, descriptive title** that identifies the problem, (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)). |
| 46 | +2. **Provide detailed reproduction steps**: |
| 47 | + - Include the exact commands you ran. |
| 48 | + - Share relevant console output. |
| 49 | + - Specify your environment (OS, Python version, if relevant, `uv` version from `uv --version`). |
| 50 | +3. **Include relevant information and versions**: |
| 51 | + - Run `eest info` to get repo and tool versions and copy the information to the issue: |
| 52 | + |
| 53 | + ```console |
| 54 | + uv run eest info |
| 55 | + ``` |
| 56 | + |
| 57 | + - Branch of execution-spec-tests you're using, if applicable. |
| 58 | + - For test failures, include the test case and failure details. |
| 59 | + - Screenshots if applicable. |
| 60 | + |
| 61 | +## Pull Requests |
| 62 | + |
| 63 | +We welcome contributions via pull requests! This section will guide you through the process. |
| 64 | + |
| 65 | +### For First-Time Contributors |
| 66 | + |
| 67 | +1. **Fork the repository** by clicking the "Fork" button on the top right of the [GitHub repository page](https://github.com/ethereum/execution-spec-tests). |
| 68 | + |
| 69 | +2. **Clone your fork** to your local machine: |
| 70 | + |
| 71 | + ```bash |
| 72 | + git clone https://github.com/YOUR-USERNAME/execution-spec-tests.git |
| 73 | + cd execution-spec-tests |
| 74 | + ``` |
| 75 | + |
| 76 | +3. **Install `uv`**: |
| 77 | + |
| 78 | + ```bash |
| 79 | + curl -LsSf https://astral.sh/uv/install.sh | sh |
| 80 | + ``` |
| 81 | + |
| 82 | +4. **Set up your environment**: |
| 83 | + |
| 84 | + ```bash |
| 85 | + uv python install 3.12 |
| 86 | + uv python pin 3.12 |
| 87 | + uv sync --all-extras |
| 88 | + uv run solc-select use 0.8.24 --always-install |
| 89 | + ``` |
| 90 | + |
| 91 | + See [installation troubleshooting](https://eest.ethereum.org/main/getting_started/installation_troubleshooting) if you encounter issues. |
| 92 | + |
| 93 | +5. **Create a branch** for your changes: |
| 94 | + |
| 95 | + ```bash |
| 96 | + git checkout -b your-branch-name |
| 97 | + ``` |
| 98 | + |
| 99 | +6. **Make your changes** according to our [code standards](https://eest.ethereum.org/main/getting_started/code_standards). |
| 100 | + |
| 101 | +7. **For EVM Tests**: Review the cases in the [EIP checklist template](./docs/writing_tests/checklist_templates/eip_testing_checklist_template.md). |
| 102 | + |
| 103 | +8. **Verify your changes** by running the appropriate checks: |
| 104 | + |
| 105 | + ```bash |
| 106 | + uvx --with=tox-uv tox -e lint,typecheck |
| 107 | + ``` |
| 108 | + |
| 109 | +9. **Commit your changes** with meaningful commit messages (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)). |
| 110 | + |
| 111 | +10. **Push your branch** to your GitHub fork: |
| 112 | + |
| 113 | + ```bash |
| 114 | + git push -u origin your-branch-name |
| 115 | + ``` |
| 116 | + |
| 117 | +10. **Create a pull request** by navigating to your fork on GitHub and clicking the "New Pull Request" button. |
| 118 | + |
| 119 | +### Branch Naming Conventions |
| 120 | + |
| 121 | +Branch names should follow this format: |
| 122 | + |
| 123 | +```text |
| 124 | +<type>/<short-description> |
| 125 | +``` |
| 126 | + |
| 127 | +Where `<type>` matches the [conventional commit](https://www.conventionalcommits.org/en/v1.0.0/) types: |
| 128 | + |
| 129 | +- `feat/` - For new features. |
| 130 | +- `fix/` - For bug fixes. |
| 131 | +- `docs/` - For documentation changes. |
| 132 | +- `test/` - For adding or modifying tests. |
| 133 | +- `refactor/` - For code refactoring. |
| 134 | +- `chore/` - For maintenance tasks. |
| 135 | + |
| 136 | +Examples: |
| 137 | + |
| 138 | +```text |
| 139 | +feat/add-cancun-blob-tests |
| 140 | +fix/prague-consume-genesis |
| 141 | +docs/improve-installation-guide |
| 142 | +``` |
| 143 | + |
| 144 | +### PR Review Process |
| 145 | + |
| 146 | +1. **Initial checks**: When you submit a PR, automated CI checks will run. Make sure all checks pass before requesting a review. |
| 147 | + |
| 148 | +2. **Requesting review**: Feel free to tag a maintainer or ask for review in a PR comment. |
| 149 | + |
| 150 | +3. **Review feedback**: Maintainers will review your code and may suggest changes. Please address all comments and engage in discussion if needed. |
| 151 | + |
| 152 | +4. **Iteration**: Make requested changes, push to your branch, and the PR will update automatically. No need to create a new PR. |
| 153 | + |
| 154 | +5. **Approval**: Once your changes are approved, a maintainer will merge your PR. |
| 155 | + |
| 156 | +### PR Expectations |
| 157 | + |
| 158 | +To increase the chances of your PR being merged quickly: |
| 159 | + |
| 160 | +- **Scope**: Keep PRs focused on a _single issue or feature_. |
| 161 | +- **CI checks**: Ensure all CI checks pass before requesting review; but do ask for help if you don't understand the fail! |
| 162 | +- **Clean history**: Use meaningful, atomic commits that can be easily understood. |
| 163 | +- **Tests**: Include tests for new functionality. |
| 164 | +- **Documentation**: Update documentation for new features or changes. |
| 165 | +- **Responsiveness**: Try to respond to review feedback within a reasonable time. |
| 166 | + |
| 167 | +### Code Standards and Enforced CI Checks |
| 168 | + |
| 169 | +We enforce lint, code formatting and unit test checks in our CI - for detailed code standards and enforcement checks, see our [Code Standards documentation](https://eest.ethereum.org/main/getting_started/code_standards). |
| 170 | + |
| 171 | +### Commits |
| 172 | + |
| 173 | +It's recommended to keep changes logically grouped into smaller, individual commits to make changes easier to review. |
| 174 | + |
| 175 | +### Commit Messages, Issue and PR Titles |
| 176 | + |
| 177 | +We use [conventional commit](https://www.conventionalcommits.org/en/v1.0.0/) messages and PR titles following the format: |
| 178 | + |
| 179 | +```console |
| 180 | +<type>(<scope>): <description> |
| 181 | +``` |
| 182 | + |
| 183 | +#### Rules |
| 184 | + |
| 185 | +- The format should be lowercase except for object names, which should be back-ticked (e.g., `FixtureCollector`). |
| 186 | +- The description should be clear and concise. |
| 187 | +- No period at the end of the title/message. |
| 188 | +- Use the imperative ("add" not "added" or "adds"). |
| 189 | +- A breaking change should be indicated by appending `!` directly after the type/scope. |
| 190 | + |
| 191 | +#### Types |
| 192 | + |
| 193 | +The following commit types are used in this repository: |
| 194 | + |
| 195 | +| `<type>` | Repo Label | Description | |
| 196 | +| -------------- | --------------- | ------------------------------------------------------------ | |
| 197 | +| `feat` | `type:feat` | A new feature | |
| 198 | +| `bug` or `fix` | `type:bug` | A bug/bug fix (`bug` in issue; `fix` in commit/PR) | |
| 199 | +| `docs` | `type:docs` | Documentation changes | |
| 200 | +| `style` | - | Formatting changes that don't affect code functionality | |
| 201 | +| `refactor` | `type:refactor` | Code changes that neither fix bugs nor add features | |
| 202 | +| `test` | `type:test` | Add, refactor, modify an EEST library or framework unit test | |
| 203 | +| `chore` | `type:chore` | Routine tasks, dependency updates, etc. | |
| 204 | + |
| 205 | +#### Scopes |
| 206 | + |
| 207 | +The following scopes are used in this repository: |
| 208 | + |
| 209 | +| `<scope>` | Repo Label | Description | |
| 210 | +| --------- | ------------------ | ---------------------------------------------- | |
| 211 | +| `fill` | `scope:fill` | Changes to `fill` command | |
| 212 | +| `execute` | `scope:execute` | Changes to the `execute` command | |
| 213 | +| `consume` | `scope:consume` | Changes to `consume` command suite | |
| 214 | +| `pytest` | `scope:pytest` | Changes that effect all EEST pytest plugins | |
| 215 | +| `evm` | `scope:evm` | Changes to the `evm_transition_tool` package | |
| 216 | +| `forks` | `scope:forks` | Changes to `ethereum_test_forks` package | |
| 217 | +| `tools` | `scope:tools` | Changes to `ethereum_test_tools` package | |
| 218 | +| `fw` | `scope:fw` | Framework changes (evm\|tools\|forks\|pytest) | |
| 219 | +| `tests` | `scope:tests` | Changes to EL client test cases in `./tests` | |
| 220 | +| `docs` | `scope:docs` | Documentation flow changes | |
| 221 | +| `ci` | `scope:ci` | Continuous Integration changes | |
| 222 | +| `gentest` | `scope:gentest` | Changes to `gentest` CLI command | |
| 223 | +| `eest` | `scope:eest` | Changes to `eest` CLI command | |
| 224 | +| `make` | `scope:make` | Changes to `eest make` command | |
| 225 | +| `tooling` | `scope:tooling` | Python tools changes (`uv`, `ruff`, `tox`,...) | |
| 226 | +| `deps` | `scope:deps` | Updates package dependencies | |
| 227 | + |
| 228 | +#### Examples |
| 229 | + |
| 230 | +This repository's main focus are the EL client tests in `./tests/` (`scope:tests`), but it contains many unit/module tests (`type:tests`) for the test generation frameworks and libraries in this repository. This can be a bit confusing, these examples demonstrate how we apply these labels and terms: |
| 231 | + |
| 232 | +```console |
| 233 | +# adds new EVM tests to tests/prague/eip7702_set_code_tx/ |
| 234 | +feat(tests): add test cases for EIP-7702 |
| 235 | + |
| 236 | +# a pure EVM test code refactor; no changes to test fixture JSON (at least not to fixture hashes, IDs might change if it's too difficult to preserve them). |
| 237 | +refactor(tests): split test setup across several fixtures |
| 238 | + |
| 239 | +# improve EVM test docstrings (these are included in HTML documentation): |
| 240 | +docs(tests): improve EIP-7623 docstrings |
| 241 | + |
| 242 | +# fix an EVM test |
| 243 | +fix(tests): EIP-7702 test authorization list nonce/gas |
| 244 | + |
| 245 | +# add unit tests for the `execute` command |
| 246 | +test(execute): add tests for output dir arguments |
| 247 | + |
| 248 | +# fix a broken unit test |
| 249 | +test(fill): fix broken unit test |
| 250 | +``` |
| 251 | + |
| 252 | +Examples of messages and titles for other types and scopes: |
| 253 | + |
| 254 | +```console |
| 255 | +feat(eest): add new test generator command |
| 256 | +fix(forks): resolve `Cancun` initialization issue |
| 257 | +docs(fill): describe new command-line args |
| 258 | +refactor(tools): improve code organization in bytecode helpers |
| 259 | +test(pytest): add tests for logging plugin |
| 260 | +chore(deps): update dependency versions |
| 261 | +``` |
| 262 | + |
| 263 | +## Merging PRs |
| 264 | + |
| 265 | +We maintain high standards for our repository history to ensure it's clean, understandable, and properly documented. Maintainers should follow these guidelines when merging PRs: |
| 266 | + |
| 267 | +### Pre-Merge Checklist |
| 268 | + |
| 269 | +1. **Review the PR template checklist** |
| 270 | + |
| 271 | + - Ensure all applicable items are checked. |
| 272 | + - Items that aren't relevant can be deleted or marked as N/A. |
| 273 | + |
| 274 | +2. **Verify changelog entry** |
| 275 | + |
| 276 | + - Every PR that impacts functionality should have a changelog entry. |
| 277 | + - The entry should clearly but concisely describe the change. |
| 278 | + - It must include a link to the PR in brackets (e.g., `([#1234](https://github.com/ethereum/execution-spec-tests/pull/1234))`). |
| 279 | + - Add any breaking changes at the top of the upcoming release section. |
| 280 | + |
| 281 | +3. **Check PR title format** |
| 282 | + |
| 283 | + - The PR title must follow the [conventional commit](https://www.conventionalcommits.org/en/v1.0.0/) format: `<type>(<scope>): <description>`. |
| 284 | + - This title will be used (suggested automatically by Github) as the squash commit message, so it's essential it's correct. |
| 285 | + - Follow the same rules as commit messages (imperative tense, no period at end, etc.). |
| 286 | + - Example: `feat(tests): add tests for EIP-7702 blob gas calculation` |
| 287 | + |
| 288 | +4. **Review PR description**: |
| 289 | + |
| 290 | + - Ensure the PR description is accurate and up-to-date. |
| 291 | + |
| 292 | +5. **Add appropriate labels**: |
| 293 | + |
| 294 | + - Ensure the PR has the appropriate labels matching its type and scope. |
| 295 | + |
| 296 | +6. **Consider other contributors/stakeholders**: |
| 297 | + |
| 298 | + - Verify the PR has been reviewed and approved by any interested contributors and/or stakeholders. |
| 299 | + |
| 300 | +### Merge Strategy |
| 301 | + |
| 302 | +We **strongly prefer squash merging** over other strategies. |
| 303 | + |
| 304 | +Exceptions to the squash merge policy may include: |
| 305 | + |
| 306 | +- Large PRs with logically separate commits that should be preserved. |
| 307 | +- Work that spans multiple distinct features or fixes. |
| 308 | + |
| 309 | +### Squash Commit Details |
| 310 | + |
| 311 | +When performing a squash merge: |
| 312 | + |
| 313 | +1. **Include PR number in the commit title** |
| 314 | + |
| 315 | + - Leave, respectively add, the PR number in parentheses at the end of the title. |
| 316 | + - Example: `feat(tests): add tests for EIP-7702 gas calculation (#1234)` |
| 317 | + |
| 318 | +2. **Clean up the extended commit message** |
| 319 | + |
| 320 | + - Delete all content in the extended message section EXCEPT: |
| 321 | + |
| 322 | + - Any `Co-authored-by:` lines, which must be preserved to properly attribute work. |
| 323 | + - The format should be `Co-authored-by: Full Name <email@example.com>` |
0 commit comments