Pull Requests

Title convention

Mirror the branch type/scope in the PR title and commit messages (Conventional Commits style):

<type>(<scope>): <short description>

feat(orchestration): add dbt profile generation
fix(utils): add timeout to Key Vault requests
chore(utils): release v0.2.1

Recommended PR body structure

## Type
- [ ] Feature
- [ ] Bug Fix
- [ ] Refactor
- [ ] Documentation
- [ ] Cosmos/dbt Integration

## Scope
Affected packages/projects (e.g., utils, orchestration, mx_fuels)

## Description
Brief description of changes

## Changes
- List of changes

## Dependencies
- Does this require updating other packages? (e.g., utils wheel rebuild)
- Are there breaking changes?

## Testing
- [ ] Unit tests added/updated
- [ ] Integration tests passed
- [ ] DAGs validated (if orchestration changes)

## Checklist
- [ ] Code follows project style (ruff, pyright)
- [ ] Documentation updated
- [ ] CHANGELOG updated (if public API change)
- [ ] Version bumped (if package release)

Multi-package changes

Single PR (preferred for tightly coupled changes): e.g. update packages/utils, rebuild the orchestration wheel (cd orchestration && make bin), update orchestration/pyproject.toml, and commit all of it together.
Stacked PRs (for independent changes): land the package change first (feat/utils-new-feature), merge, then open a second PR for the consumer (feat/orchestration-use-utils-feature).

Releasing a shared package

Run tests/lint/typecheck: pytest packages/utils/..., ruff check packages/utils, pyright packages/utils
Bump version in the package’s pyproject.toml
If consumed by orchestration/, rebuild the wheel: cd orchestration && make bin, and update orchestration/pyproject.toml’s [tool.uv.sources] path + cache-keys
Commit, tag (git tag utils-v0.2.1), and push with tags: git push origin main --tags
Update the package’s CHANGELOG if the public API changed

See File & Document Naming for package versioning rules.