- GHA release workflow is updated to use an action for uploading all assets. The action docs say it updates a release if one already exists, and since this triggers on release and we pass a release tag we know the release already exists. - GHA release candidate workflow is updated to auto-publish a pre-release release on push to a `release/**` branch. A script is added and used to generate a release message made up of the commits since the last release of any kind. - ACT profiles are added to allow locally testing these workflows without needing to push and wait for GHA to run. - Docs are updated to note how to test the workflows locally.
46 lines
1.6 KiB
Markdown
46 lines
1.6 KiB
Markdown
# Development Workflow
|
|
|
|
This page defines the expected local workflow before opening a pull request.
|
|
|
|
## 1) Fork and create a focused branch
|
|
|
|
- Fork the repository to your own GitHub account
|
|
- Clone your fork locally and add the upstream repository if needed
|
|
- Enable repo hooks once per clone: `git config core.hooksPath .githooks && chmod +x .githooks/pre-commit`
|
|
|
|
- Branch from `master`
|
|
- Keep each PR focused on one fix or feature area
|
|
|
|
## 2) Implement with scope in mind
|
|
|
|
- Confirm your idea is in project scope: [SCOPE.md](../../SCOPE.md)
|
|
- Prefer incremental changes over broad refactors
|
|
|
|
## 3) Run local checks
|
|
|
|
```sh
|
|
./bin/clang-format-fix
|
|
pio check --fail-on-defect low --fail-on-defect medium --fail-on-defect high
|
|
pio run
|
|
```
|
|
|
|
CI enforces formatting, static analysis, and build checks.
|
|
Use clang-format 21+ locally to match CI.
|
|
If `clang-format` is missing or too old locally, see [Getting Started](./getting-started.md).
|
|
If your change affects release automation, also dry-run the release workflows locally with `act` before opening the PR. See [Testing and Debugging](./testing-debugging.md#test-release-workflows-locally-with-act).
|
|
|
|
## 4) Open the PR
|
|
|
|
- Use a semantic title (example: `fix: avoid crash when opening malformed epub`)
|
|
- Fill out `.github/PULL_REQUEST_TEMPLATE.md`
|
|
- Describe the problem, approach, and any tradeoffs
|
|
- Include reproduction and verification steps for bug fixes
|
|
|
|
## 5) Review etiquette
|
|
|
|
- Be explicit and concise in responses
|
|
- Keep discussions technical and respectful
|
|
- Assume good intent and focus on code-level feedback
|
|
|
|
For community expectations, see [GOVERNANCE.md](../../GOVERNANCE.md).
|