Files
verl/CONTRIBUTING.md
H d0c7bbbc05 [cfg] refactor: support +extra.any_key usage for the base dataclass config in verl (#2502)
### What does this PR do?

This PR makes update to the base config in verl:
- support +extra.any_key usage for the base config in verl.
- allow selective subfields to be frozen
- add a auto-generated config yaml file
`verl/trainer/config/_generated_ppo_trainer.yaml` for reference purpose,
in case the nested inheritance structure makes the config information
too scattered

### Checklist Before Starting

- [x] Search for similar PRs. Paste at least one query link here: ...
- [x] Format the PR title as `[{modules}] {type}: {description}` (This
will be checked by the CI)
- `{modules}` include `fsdp`, `megatron`, `sglang`, `vllm`, `rollout`,
`trainer`, `ci`, `training_utils`, `recipe`, `hardware`, `deployment`,
`ray`, `worker`, `single_controller`, `misc`, `perf`, `model`, `algo`,
`env`, `tool`, `ckpt`, `doc`, `data`
- If this PR involves multiple modules, separate them with `,` like
`[megatron, fsdp, doc]`
  - `{type}` is in `feat`, `fix`, `refactor`, `chore`, `test`
- If this PR breaks any API (CLI arguments, config, function signature,
etc.), add `[BREAKING]` to the beginning of the title.
  - Example: `[BREAKING][fsdp, megatron] feat: dynamic batching`

### Test

- added frozen field tests

### API and Usage Example

> Demonstrate how the API changes if any, and provide usage example(s)
if possible.

Now you can pass `--xx.profiler.extra.any_new_key=any_plain_value` in
command line to a dataclass inheriting `verl.BaseConfig`. This way we
can still pass dataclass configs inside verl but allow some flexiblity
in accepting new keys from users' adhoc usage.


### Checklist Before Submitting

> [!IMPORTANT]
> Please check all the following items before requesting a review,
otherwise the reviewer might deprioritize this PR for review.

- [x] Read the [Contribute
Guide](https://github.com/volcengine/verl/blob/main/CONTRIBUTING.md).
- [x] Apply [pre-commit
checks](https://github.com/volcengine/verl/blob/main/CONTRIBUTING.md#code-linting-and-formatting):
`pre-commit install && pre-commit run --all-files --show-diff-on-failure
--color=always`
- [ ] Add / Update [the
documentation](https://github.com/volcengine/verl/tree/main/docs).
- [ ] Add unit or end-to-end test(s) to [the CI
workflow](https://github.com/volcengine/verl/tree/main/.github/workflows)
to cover all the code. If not feasible, explain why: ...
- [ ] Once your PR is ready for CI, send a message in [the `ci-request`
channel](https://verl-project.slack.com/archives/C091TCESWB1) in [the
`verl` Slack
workspace](https://join.slack.com/t/verl-project/shared_invite/zt-3855yhg8g-CTkqXu~hKojPCmo7k_yXTQ).

---------

Co-authored-by: Lin <haibin@Lins-Laptop.hsd1.wa.comcast.net>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
2025-07-15 09:06:56 +08:00

3.7 KiB

Contributing to verl

Thank you for considering a contribution to verl! We welcome contributions of any kind - bug fixes, enhancements, documentation improvements, or even just feedback. Whether you're an experienced developer or this is your first open-source project, your help is invaluable.

Your support can take many forms:

  • Report issues or unexpected behaviors.
  • Suggest or implement new features.
  • Improve or expand documentation.
  • Review pull requests and assist other contributors.
  • Spread the word: share verl in blog posts, social media, or give the repo a .

Finding Issues to Contribute

Looking for ways to dive in? Check out these issues:

Developing

  • Python-only: install verl via pip install -e .[test,vllm] or pip install -e .[test,sglang] and iterate quickly. For full dependency setup, check out the verl installation doc.

Code Linting and Formatting

We rely on pre-commit to keep our code consistent. To set it up:

pip install pre-commit
pre-commit install
# for staged changes
pre-commit run
# for all files in the repo
pre-commit run --all-files
# run a specific hook with pre-commit
# pre-commit run --all-files --show-diff-on-failure --color=always <hood-id>
pre-commit run --all-files --show-diff-on-failure --color=always ruff
pre-commit run --all-files --show-diff-on-failure --color=always autogen-trainer-cfg

Testing

Our test suites run on GitHub Actions. Check these workflows for details:

Adding CI tests

If possible, please add CI test(s) for your new feature:

  1. Find the most relevant workflow yml file, which usually corresponds to a hydra default config (e.g. ppo_trainer, ppo_megatron_trainer, sft_trainer, etc).
  2. Add related path patterns to the paths section if not already included.
  3. Minimize the workload of the test script(s) (see existing scripts for examples).

Building the Docs

# Ensure verl is on your PYTHONPATH, e.g.:
pip install -e .[test]

# Install documentation dependencies
pip install -r requirements-docs.txt

# Generate HTML docs
make clean
make html

# Preview locally
python -m http.server -d _build/html/

Open your browser at http://localhost:8000 to explore the docs.

Pull Requests & Code Reviews

Thanks for submitting a PR! To streamline reviews:

  • Follow our Pull Request Template for title format and checklist.
  • Adhere to our pre-commit lint rules and ensure all checks pass.
  • Update docs for any user-facing changes.
  • Add or update tests in the CI workflows, or explain why tests aren't applicable.

License

See the LICENSE file for full details.

Thank You

We appreciate your contributions to verl. Your efforts help make the project stronger and more user-friendly. Happy coding!