Add changelog and changelog verifier

Signed-off-by: Harsha Vamsi Kalluri <[email protected]>

.github/pull_request_template.md

@@ -0,0 +1,16 @@
+### Description
+[Describe what this change achieves]
+
+### Issues Resolved
+[List any issues this PR will resolve]
+
+### Check List
+- [ ] New functionality includes testing.
+  - [ ] All tests pass
+- [ ] New functionality has been documented.
+  - [ ] New functionality has comments added
+- [ ] Commits are signed per the DCO using --signoff
+- [ ] Commit changes are listed out in CHANGELOG.md file (See: [Changelog](https://github.com/opensearch-project/opensearch-js/blob/main/CONTRIBUTING.md#changelog))
+
+By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
+For more information on following Developer Certificate of Origin and signing off your commits, please check [here](https://github.com/opensearch-project/opensearch-js/blob/main/CONTRIBUTING.md#developer-certificate-of-origin).

.github/workflows/changelog_verifier.yml

@@ -0,0 +1,18 @@
+name: "Changelog Verifier"
+on:
+  pull_request:
+    types: [opened, edited, review_requested, synchronize, reopened, ready_for_review, labeled, unlabeled]
+
+jobs:
+  # Enforces the update of a changelog file on every pull request
+  verify-changelog:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+        with:
+          token: ${{ secrets.GITHUB_TOKEN }}
+          ref: ${{ github.event.pull_request.head.sha }}
+
+      - uses: dangoslen/changelog-enforcer@v3
+        with:
+          skipLabels: "autocut"

CHANGELOG.md

@@ -0,0 +1,19 @@
+# CHANGELOG
+Inspired from [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
+
+## [Unreleased]
+### Added
+- Github workflow for changelog verification ([#239](https://github.com/opensearch-project/opensearch-js/pull/239))
+
+### Changed
+
+### Deprecated
+
+### Removed
+
+### Fixed
+
+### Security
+
+
+[Unreleased]: https://github.com/opensearch-project/opensearch-js/compare/2.0...HEAD

CONTRIBUTING.md

@@ -5,6 +5,8 @@
   - [Feature Requests](#feature-requests)
   - [Contributing Code](#contributing-code)
 - [Developer Certificate of Origin](#developer-certificate-of-origin)
+- [Changelog](#changelog)
+  - [How to add my changes to CHANGELOG?](#how-to-add-my-changes-to-changelog)
 - [Review Process](#review-process)
 
 ## Contributing to OpenSearch
@@ -84,6 +86,22 @@ Signed-off-by: Jane Smith <[email protected]>
 
 You may type this line on your own when writing your commit messages. However, if your user.name and user.email are set in your git configs, you can use `-s` or `– – signoff` to add the `Signed-off-by` line to the end of the commit message.
 
+## Changelog
+
+OpenSearch-JS maintains version specific changelog by enforcing a change to the ongoing [CHANGELOG](CHANGELOG.md) file adhering to the [Keep A Changelog](https://keepachangelog.com/en/1.0.0/) format.
+
+Briefly, the changes are curated by version, with the changes to the main branch added chronologically to `Unreleased` version. Further, each version has corresponding sections which list out the category of the change - `Added`, `Changed`, `Deprecated`, `Removed`, `Fixed`, `Security`.
+
+
+### How to add my changes to [CHANGELOG](CHANGELOG.md)?
+
+As a contributor, you must ensure that every pull request has the changes listed out within the corresponding version and appropriate section of [CHANGELOG](CHANGELOG.md) file.
+
+Adding in the change is two step process -
+1. Add your changes to the corresponding section within the CHANGELOG file with dummy pull request information, publish the PR
+
+2. Update the entry for your change in [`CHANGELOG.md`](CHANGELOG.md) and make sure that you reference the pull request there.
+
 ## Review Process
 
 We deeply appreciate everyone who takes the time to make a contribution. We will review all contributions as quickly as possible. As a reminder, [opening an issue](https://github.com/opensearch-project/opensearch-js/issues/new/choose) discussing your change before you make it is the best way to smooth the PR process. This will prevent a rejection because someone else is already working on the problem, or because the solution is incompatible with the architectural direction.