Skip to content

Latest commit

 

History

History
48 lines (39 loc) · 3.65 KB

CONTRIBUTING.md

File metadata and controls

48 lines (39 loc) · 3.65 KB

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).

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.

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.