We welcome feature requests, bug reports and contributions for code and documentation.
Reporting bugs can be done in the GitHub issue tracker. Please search for existing issues first to help prevent duplicates.
Please include the version (goalert version
) with new bug reports.
GoAlert is already used in production environments, so any new changes/features/functionality must, where possible:
- Not alter existing behavior without an explicit config change
- Co-exist with older versions without disruption
- Must have a safe way to disable/roll-back
It should always be safe to roll out a new version of GoAlert into an existing environment/deployment without downtime.
As an example, things like DB changes/migrations should preserve behavior across revisions.
Patches are welcome, but we ask that any significant change start as an issue in the tracker, preferably before work is started.
More information is available for complex features.
Be sure to run make check
and tests before opening a PR to catch common errors.
- Complex logic should be broken out with corresponding unit tests (we use Jest) into the same directory. For example: util.js and util.test.js.
- New functionality should have an integration test (we use Cypress for these) testing the happy-path at a minimum. Examples here, and more information here.
- React components should follow React idioms, using common prop names, and having prop-types defined.
- Use unit tests as a tool to validate complex logic. For example.
- New functionality should have a behavioral smoke test at a minimum. For example. Documentation on our smoke test framework can be found here.
- Go code should follow best practices, exported functions/methods should be commented, etc..
GoAlert utilizes 3 main types of testing as tools for different purposes:
- Unit tests are used for complicated logic and exhaustive edge-case testing and benchmarking. They live with the code being tested:
- Smoke tests (in
test/smoke
) are used to ensure main functionality and things like behavioral compatibility with future versions & DB migrations. These focus on hard guarantees like deliverability and preserving intent as the application and datastore evolves and changes over time. - Integration tests (currently under
web/src/cypress/integration
) are primarily used to validate happy-path flows work end-to-end, and any important/common error scenarios. They are focused on UX and high-level functionality.