Files
Crosspoint/docs/contributing/development-workflow.md
T
Joel Goguen 0010b200ed feat(gha): Auto-publish releases
- 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.
2026-04-23 22:48:41 -04:00

1.6 KiB

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
  • Prefer incremental changes over broad refactors

3) Run local checks

./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. If your change affects release automation, also dry-run the release workflows locally with act before opening the PR. See Testing and Debugging.

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.