ci: Introduce automatic release PR creation with release-please

.github/.release-please-manifest.json

@@ -0,0 +1 @@
+{".": "3.8.3"}

.github/release-please-config.json

@@ -0,0 +1,15 @@
+{
+  "$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json",
+  "release-type": "node",
+  "include-component-in-tag": false,
+  "pull-request-title-pattern": "chore: Release ${version}",
+  "always-update": true,
+  "skip-github-release": false,
+  "skip-changelog": false,
+  "skip-pull-request": false,
+  "packages": {
+    ".": {
+      "release-type": "node"
+    }
+  }
+}

.github/workflows/lint-pr-title.yaml

@@ -0,0 +1,20 @@
+name: "Lint Pull Request Title"
+
+on:
+  pull_request_target:
+    types:
+      - opened
+      - edited
+      - synchronize
+
+permissions:
+  pull-requests: read
+
+jobs:
+  main:
+    name: Lint PR title
+    runs-on: ubuntu-latest
+    steps:
+      - uses: amannn/action-semantic-pull-request@48f256284bd46cdaab1048c3721360e808335d50 # v6.1.1
+        env:
+          GITHUB_TOKEN: ${{ github.token }}

.github/workflows/release-please.yaml

@@ -0,0 +1,32 @@
+name: Prepare release
+
+on:
+  push:
+    branches:
+      - main
+
+permissions:
+  contents: write
+  issues: write
+  pull-requests: write
+
+
+jobs:
+  release-please:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Generate a token
+        id: generate_token
+        uses: actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 # v3.2.0
+        with:
+          client-id: ${{ secrets.GH_BOT_APP_ID }}
+          private-key: ${{ secrets.GH_BOT_APP_KEY }}
+          owner: ${{ github.repository_owner }}
+          repositories: device-agent
+
+      - name: Run Release Please
+        uses: googleapis/release-please-action@45996ed1f6d02564a971a2fa1b5860e934307cf7 # v5.0.0
+        with:
+          token: ${{ steps.generate_token.outputs.token }}
+          config-file: .github/release-please-config.json
+          manifest-file: .github/.release-please-manifest.json

CHANGELOG.md

@@ -1,3 +1,5 @@
+# CHANGELOG
+
 #### 3.8.3 Release
 
  - Add kube doc (#591)

README.md

@@ -343,3 +343,49 @@ The following scripts are available:
  - `npm run test` - Run all unit tests
  - `npm run test:lib` - Run the unit tests for the lib
  - `npm run test:frontend` - Run the unit tests for the frontend
+
+## Release process
+
+In this project, the [Release Please](https://github.com/googleapis/release-please) is used to automatically determine the next release version based on the commit messages in the codebase. 
+
+By using the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/), the project adheres to a standardized format for commit messages, which `Release Please` uses to determine whether the next release should be a major, minor, or patch release.
+
+### Components
+
+1. The `Prepare release` GitHub Action workflow:
+
+    * A Release Please action that analyzes commit messages to determine the type of release required (major, minor, patch) based on the Conventional Commits specification
+    * Creates a pre-release pull request with the proposed version bump and changelog
+    * Once merged, automatically updates the version number in `package.json` and creates a new release on GitHub with the appropriate changelog
+
+2. The `Lint Pull Request Title` GitHub Action workflow:
+
+    * A workflow that runs on pull request creation and uses the `amannn/action-semantic-pull-request` action to validate that pull request titles follow the Conventional Commits format
+    * Together with adjusted default merge commit message, this ensures that all commits merged into the main branch adhere to the expected format, allowing Release Please to function correctly
+
+
+### Pull Request Title Format
+
+The Conventional Commits preset expects pull request titles to be in the following format:
+
+```
+<type>(<scope>): <subject>
+```
+
+* Type: Describes the category of the commit. Examples include:
+    * `feat`: A new feature (triggers a minor version bump).
+    * `fix`: A bug fix (triggers a patch version bump).
+    * `perf`: A code change that improves performance (triggers a patch version bump).
+    * `refactor`: A code change that neither fixes a bug nor adds a feature (does not trigger a release unless it's accompanied by a BREAKING CHANGE).
+    * `docs`: Documentation-only changes (does not trigger a release).
+    * `chore`: Changes to the build process or auxiliary tools and libraries (does not trigger a release).
+* Scope: An optional part that provides additional context about what was changed (e.g., module, component).
+* Subject: A brief description of the changes.
+
+### Handling Breaking Changes
+
+To indicate a breaking change, the exclamation mark `!` should be used immediately after the type/scope:
+
+* `feat!:,` 
+* `fix!:`
+* `refactor!:`