aws / random-cut-forest-by-aws

An implementation of the Random Cut Forest data structure for sketching streaming data, with support for anomaly detection, density estimation, imputation, and more.
https://github.com/aws/random-cut-forest-by-aws
Apache License 2.0
206 stars 33 forks source link

adding release notes workflow #370

Closed amitgalitz closed 1 year ago

amitgalitz commented 1 year ago

Description of changes:

This PR adds a workflow to easily add release notes from any PRs after this (same as OpenSearch Org uses). If we want to correspond a PR to a specific type of change (infra, bug fix, enhancement and etc.) we can simply add a label to the PR. These can always be easily edited in the releases section of github as well. Also making a small change to server id for maven release as we use the staging plugin in our pom file which caused the issues with auto release that could only be caught in official releases.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

dblock commented 1 year ago

You might want to add something like https://github.com/opensearch-project/opensearch-java/blob/main/RELEASING.md that explains how to make a release. Also take a look at the implementation in that repo and maybe in https://github.com/acm19/aws-request-signing-apache-interceptor, both are fully hands off now, single click release.

amitgalitz commented 1 year ago

You might want to add something like https://github.com/opensearch-project/opensearch-java/blob/main/RELEASING.md that explains how to make a release. Also take a look at the implementation in that repo and maybe in https://github.com/acm19/aws-request-signing-apache-interceptor, both are fully hands off now, single click release.

Added RELEASING.md with latest commit. I also took a look at the implementation of the repos you mentioned. It is not as easy to swap for the opensearch-java way as it uses some gradle methods but I can open an issue on the effort it takes to eventually move to gradle here. It also uses the jenkins infra and workflow that this repo doesn't have. For the other request-signing repo, we could definitely move to something closer to that in the future but will take a little more effort and also I know in OpenSearch we were against any Github actions auto merging changes but we can do it so a PR is opened. I propose to first release RCF this way successfully and we can re-evaluate improvements here if that makes sense.