Skip to content

Latest commit

 

History

History
51 lines (41 loc) · 3.89 KB

CONTRIBUTING.md

File metadata and controls

51 lines (41 loc) · 3.89 KB
Raw

Contributing to ElastAlert 2

Guidelines

PRs are welcome, but must include tests, when possible. PRs will not be merged if they do not pass the automated CI workflows. To test your changes before creating a PR, run sudo make clean; sudo make test-docker from the root of the repository (requires Docker to be running on your machine).

Make sure you follow the existing coding style from the existing codebase. Do not reformatting the existing code to fit your own personal style.

Before submitting the PR review that you have included the following changes, where applicable:

  • Documentation: If you're adding new functionality, any new configuration options should be documented appropriately in the docs/ folder.
  • Helm Chart: If your new feature introduces settings consider adding those to the Helm chart README.md and values.yaml
  • Examples: If your new feature includes new configuration options, review the Example config file to see if they should be added there for consistency with other configuration options.
  • Change log: Describe your contribution to the appropriate section(s) for the Upcoming release, in the CHANGELOG.md file.
  • Schema: Update the schema.yaml file with new parameters for existing and new alerters and rule types.

Releases

STOP - DO NOT PROCEED! This section is only applicable to project administrators. PR contributors do not need to follow the below procedure.

As ElastAlert 2 is a community-maintained project, releases will typically contain unrelated contributions without a common theme. It's up to the maintainers to determine when the project is ready for a release, however, if you are looking to use a newly merged feature that hasn't yet been released, feel free to open a discussion and let us know.

Maintainers, when creating a new release, follow the procedure below:

  1. Determine an appropriate new version number in the format a.b.c, using the following guidelines:
    • The major version (a) should not change.
    • The minor version (b) should be incremented if a new feature has been added or if a bug fix will have a significant user-impact. Reset the patch version to zero if the minor version is incremented.
    • The patch version (c) should be incremented when low-impact bugs are fixed, or security vulnerabilities are patched.
  2. Ensure the following are updated before publishing/tagging the new release:
    • setup.py: Match the version to the new release version
    • Chart.yaml: Match chart version and the app version to the new release version (typically keep them in sync)
    • values.yaml: Match the default image version to the new release version.
    • Chart README.md: Match the default image version to the new release version.
    • Docs: Match the default image version to the new release version.
    • CHANGELOG.md: This must contain all PRs and any other relevent notes about this release
  3. Publish a new release.
    • The title (and tag) of the release will be the same value as the new version determined in step 1.
    • Paste the new version change notes from CHANGELOG.md into the description field.
    • Check the box to 'Create a discussion for this release'.
  4. Verify that artifacts have been published:
    • Python PIP package was published successfully.
    • Helm chart has been published successfully.
    • Container image was published successfully.