|
| 1 | +# Contributing to Dify Plugin SDK |
| 2 | + |
| 3 | +This guide reflects the repository's current local tooling and GitHub Actions |
| 4 | +checks. |
| 5 | + |
| 6 | +Use `just` for routine development. Direct |
| 7 | +[`uv`](https://docs.astral.sh/uv/), `ruff`, `pytest`, and |
| 8 | +[`prek`](https://prek.j178.dev/) usage is still fine when you need a targeted |
| 9 | +command. |
| 10 | + |
| 11 | +## Development Setup |
| 12 | + |
| 13 | +### Requirements |
| 14 | + |
| 15 | +- Python 3.12 or 3.13 |
| 16 | +- [`uv`](https://docs.astral.sh/uv/) |
| 17 | +- [`just`](https://github.com/casey/just) |
| 18 | +- `git` |
| 19 | + |
| 20 | +The package declares `requires-python = ">=3.12"`. CI currently validates |
| 21 | +Python 3.12 and 3.13. |
| 22 | + |
| 23 | +### Bootstrap |
| 24 | + |
| 25 | +```bash |
| 26 | +just dev |
| 27 | +# optional for interactive work |
| 28 | +source .venv/bin/activate |
| 29 | +``` |
| 30 | + |
| 31 | +`just dev` will: |
| 32 | + |
| 33 | +- run `uv sync` |
| 34 | +- install [`prek`](https://prek.j178.dev/) Git hooks |
| 35 | + |
| 36 | +The repository uses [`uv`](https://docs.astral.sh/uv/) for dependency and |
| 37 | +virtual environment management. The default development environment includes |
| 38 | +`pytest`, `pytest-cov`, `pytest-mock`, `pytest-xprocess`, `ruff`, `ty`, and |
| 39 | +[`prek`](https://prek.j178.dev/). |
| 40 | + |
| 41 | +### Git Hooks |
| 42 | + |
| 43 | +`just dev` installs [`prek`](https://prek.j178.dev/) hooks from |
| 44 | +[`prek.toml`](prek.toml). |
| 45 | + |
| 46 | +The current hook set includes: |
| 47 | + |
| 48 | +- trailing whitespace and end-of-file cleanup |
| 49 | +- large file, case conflict, symlink, merge conflict, and private key checks |
| 50 | +- JSON, JSON5, TOML, YAML, and XML validation |
| 51 | +- line ending normalization and BOM cleanup |
| 52 | +- executable shebang checks |
| 53 | +- local `just check` |
| 54 | + |
| 55 | +Useful direct commands: |
| 56 | + |
| 57 | +```bash |
| 58 | +uv run prek install |
| 59 | +uv run prek run -a |
| 60 | +uv run prek list |
| 61 | +uv run prek validate-config |
| 62 | +``` |
| 63 | + |
| 64 | +Use `just` by default. For targeted work, direct tool usage is still fine: |
| 65 | + |
| 66 | +```bash |
| 67 | +uv run ruff check src/dify_plugin/path.py |
| 68 | +uv run pytest tests/path/test_file.py -k keyword |
| 69 | +uv run prek run -a |
| 70 | +``` |
| 71 | + |
| 72 | +## Testing and Validation |
| 73 | + |
| 74 | +Use these commands for normal development: |
| 75 | + |
| 76 | +- `just format`: run `uv run ruff format` |
| 77 | +- `just lint`: run `uv run ruff check` |
| 78 | +- `just check`: run `uv lock --check`, `ruff format --check --diff`, and |
| 79 | + `ruff check` |
| 80 | +- `just test`: run `uv run pytest` |
| 81 | +- `just docs`: generate schema documentation into `.mkdocs/docs/schema.md` |
| 82 | +- `just build`: build source and wheel distributions |
| 83 | +- `just clean`: remove local build, test, and lint artifacts |
| 84 | + |
| 85 | +Notes: |
| 86 | + |
| 87 | +- `just lint` is non-mutating in this repository. |
| 88 | +- `ruff` has `fix = true` in [`pyproject.toml`](pyproject.toml), but the |
| 89 | + current `just lint` command does not pass `--fix`. |
| 90 | +- `just check` is the non-mutating validation entrypoint used by PR checks and |
| 91 | + Git hooks. |
| 92 | +- `just test` does not run `just check`; run both before opening a pull request |
| 93 | + when the change affects behavior or public interfaces. |
| 94 | +- Integration tests that need the Dify plugin CLI are skipped when the binary is |
| 95 | + unavailable. CI installs it with |
| 96 | + [`scripts/setup-dify-plugin-cli.sh`](scripts/setup-dify-plugin-cli.sh) before |
| 97 | + running tests. |
| 98 | +- If you change dependencies, refresh and commit [`uv.lock`](uv.lock) before |
| 99 | + opening a pull request. |
| 100 | + |
| 101 | +For most changes, a good local sequence is: |
| 102 | + |
| 103 | +```bash |
| 104 | +just check |
| 105 | +just test |
| 106 | +just build |
| 107 | +``` |
| 108 | + |
| 109 | +Run `just docs` when SDK schema documentation may have changed. |
| 110 | + |
| 111 | +### CI Checks |
| 112 | + |
| 113 | +Pull requests targeting `main` currently run these checks: |
| 114 | + |
| 115 | +1. PR title validation with `amannn/action-semantic-pull-request` |
| 116 | +2. `just check` on Python 3.12, including `uv.lock` freshness validation |
| 117 | +3. `just test` on Python 3.12 and 3.13 through the reusable test workflow |
| 118 | + |
| 119 | +The test workflow installs the Dify plugin CLI, runs `just dev`, and then runs |
| 120 | +`just test`. |
| 121 | + |
| 122 | +Pushes to `main` also run the MkDocs workflow. It runs `just docs` on Python |
| 123 | +3.12 and deploys `.mkdocs` to GitHub Pages. |
| 124 | + |
| 125 | +Keep local workflow aligned with those checks. A green local `just check` plus |
| 126 | +`just test` is useful, but it is not a complete substitute for CI because CI |
| 127 | +also validates PR titles and a Python version matrix. |
| 128 | + |
| 129 | +## Git Commits |
| 130 | + |
| 131 | +This repository enforces |
| 132 | +[Conventional Commits](https://www.conventionalcommits.org/) for commit |
| 133 | +messages. The same format is required for pull request titles. |
| 134 | + |
| 135 | +The PR title validator currently accepts these types: |
| 136 | + |
| 137 | +- `feat` |
| 138 | +- `fix` |
| 139 | +- `docs` |
| 140 | +- `style` |
| 141 | +- `refactor` |
| 142 | +- `perf` |
| 143 | +- `test` |
| 144 | +- `build` |
| 145 | +- `ci` |
| 146 | +- `chore` |
| 147 | +- `revert` |
| 148 | + |
| 149 | +Rules: |
| 150 | + |
| 151 | +- use an optional scope when it improves clarity |
| 152 | +- mark breaking changes with `!` |
| 153 | +- keep branch names aligned with the same type and scope vocabulary |
| 154 | +- remember that the pull request title becomes the squash merge commit message |
| 155 | + |
| 156 | +Examples: |
| 157 | + |
| 158 | +```text |
| 159 | +feat(model): add polling result validation |
| 160 | +fix(runtime): close sessions after stream errors |
| 161 | +docs(contributing): clarify local validation |
| 162 | +refactor(server)!: remove deprecated transport entrypoint |
| 163 | +``` |
| 164 | + |
| 165 | +Branch name examples: |
| 166 | + |
| 167 | +```text |
| 168 | +feat/model-polling-validation |
| 169 | +fix/runtime-session-cleanup |
| 170 | +docs/contributing-guide |
| 171 | +``` |
| 172 | + |
| 173 | +## Issues |
| 174 | + |
| 175 | +Before you start implementation or open a new issue, search the existing open |
| 176 | +and closed issues and pull requests to confirm the work is not already tracked |
| 177 | +or in progress. |
| 178 | + |
| 179 | +Rules: |
| 180 | + |
| 181 | +- self-assign every issue you create or work on |
| 182 | +- do not open duplicate issues or parallel pull requests for the same change |
| 183 | +- if related work already exists, continue that discussion instead of starting a |
| 184 | + new thread |
| 185 | +- if no issue exists for the change, create one before opening a pull request |
| 186 | +- if GitHub presents an issue template or issue form, fill out every required |
| 187 | + field and keep the provided structure intact |
| 188 | + |
| 189 | +## Pull Requests |
| 190 | + |
| 191 | +Every pull request must be linked to an issue. Use a closing or reference |
| 192 | +keyword such as `Closes #123`, `Fixes #123`, or `Refs #123` in the pull request |
| 193 | +body. |
| 194 | + |
| 195 | +Before you open a pull request: |
| 196 | + |
| 197 | +- search existing pull requests again to confirm there is no duplicate review in |
| 198 | + progress |
| 199 | +- self-assign the pull request |
| 200 | +- make sure the change stays focused and reviewable |
| 201 | +- run `just check` and `just test` |
| 202 | +- run `just build` when the change affects packaging, project metadata, or SDK |
| 203 | + distribution behavior |
| 204 | + |
| 205 | +When you open a pull request: |
| 206 | + |
| 207 | +- use a Conventional Commits title, and mark breaking changes with `!`, because |
| 208 | + the pull request title becomes the squash merge commit message |
| 209 | +- link the related issue in the pull request body |
| 210 | +- follow |
| 211 | + [`.github/pull_request_template.md`](.github/pull_request_template.md) |
| 212 | + exactly |
| 213 | +- do not delete required headings or checklist items from the template; if a |
| 214 | + section is not applicable, say so explicitly |
| 215 | +- add or update tests for behavior changes unless the change genuinely does not |
| 216 | + require them |
| 217 | +- update contributor-facing or user-facing documentation when needed |
| 218 | +- describe compatibility impact for changes that affect SDK APIs, plugin |
| 219 | + manifests, generated schema documentation, examples, or runtime behavior |
| 220 | + |
| 221 | +## Maintainer Notes |
| 222 | + |
| 223 | +Version updates are managed manually with [`uv`](https://docs.astral.sh/uv/) |
| 224 | +`version`: |
| 225 | + |
| 226 | +```bash |
| 227 | +uv version --no-sync --bump patch |
| 228 | +uv version --no-sync --bump minor |
| 229 | +uv version --no-sync --bump major |
| 230 | +``` |
| 231 | + |
| 232 | +Those commands update the package version in |
| 233 | +[`pyproject.toml`](pyproject.toml). If the lock file also needs to reflect the |
| 234 | +new root package version, refresh and commit [`uv.lock`](uv.lock) as part of |
| 235 | +the version bump change. |
| 236 | + |
| 237 | +Release tags use the `v` prefix and are intended to be created from `main` |
| 238 | +after the version bump pull request has been merged. The pushed tag must match |
| 239 | +`[project].version` in [`pyproject.toml`](pyproject.toml). |
| 240 | + |
| 241 | +Pushing `vX.Y.Z` triggers the release workflow. It: |
| 242 | + |
| 243 | +1. verifies the tag matches `pyproject.toml` and points to a commit reachable |
| 244 | + from `main` |
| 245 | +2. runs tests before building release distributions |
| 246 | +3. builds source and wheel distributions with `just build` |
| 247 | +4. creates or updates a GitHub draft release |
| 248 | +5. publishes the same build artifacts to TestPyPI |
| 249 | +6. waits for approval on the `pypi` environment |
| 250 | +7. publishes the same build artifacts to PyPI and publishes the GitHub draft |
| 251 | + release |
0 commit comments