Categorize the on-boarding document to plugins and standalone compone…

…nts (opensearch-project#4321)

Signed-off-by: Sayali Gaikawad <gaiksaya@amazon.com>

.github/ISSUE_TEMPLATE/plugin_onboarding_template.yaml

@@ -1,6 +1,6 @@
 ---
-name: On-board plugins
-description: On-board plugins
+name: On-board plugins to the distribution
+description: On-board plugins to the distribution
 title: '[On-boarding]: '
 labels: [on-boarding, untriaged]
 body:
@@ -38,7 +38,7 @@ body:
       required: true
   - type: textarea
     attributes:
-      description: 'Did you go through the [on-boarding document](https://github.com/opensearch-project/opensearch-build/blob/main/ONBOARDING.md)'
+      description: 'Did you go through the [on-boarding document](https://github.com/opensearch-project/opensearch-build/blob/main/ONBOARDING.md#plugin-onboarding)'
       label: 'Did you read the on-boarding document'
     id: document
     validations:

.github/ISSUE_TEMPLATE/standalone_releases_template.yaml

@@ -10,7 +10,7 @@ body:
         Thanks for taking the time to submit release request!
   - type: textarea
     attributes:
-      description: 'Did you go through the [on-boarding document](https://github.com/opensearch-project/opensearch-build/blob/main/ONBOARDING.md#onboarding-to-universal--1-click-release-process)'
+      description: 'Did you go through the [on-boarding document](https://github.com/opensearch-project/opensearch-build/blob/main/ONBOARDING.md#standalone-component-onboarding)'
       label: 'Did you read the on-boarding document'
     id: document
     validations:

ONBOARDING.md

@@ -1,13 +1,14 @@
 
-- [Component Onboarding](#component-onboarding)
+- [Plugin Onboarding](#plugin-onboarding)
   - [Onboard to OpenSearch Meta](#onboard-to-opensearch-meta)
     - [opensearch-plugins](#opensearch-plugins)
   - [Onboard to Build Workflow](#onboard-to-build-workflow)
-  - [Onboard to `test-workflow`](#onboard-to-test-workflow)
-- [Onboarding to universal/1-click release process](#onboarding-to-universal--1-click-release-process)
-- [Onboard to PyPi GitHub Action release](#onboard-to-pypi-github-action-release)
+  - [Onboard to Test Workflow](#onboard-to-test-workflow)
+- [Standalone component Onboarding](#standalone-component-onboarding)
+    - [Onboarding to universal/1-click release process](#onboarding-to-universal--1-click-release-process)
+    - [Onboard to PyPi GitHub Action release](#onboard-to-pypi-github-action-release)
 
-## Component Onboarding
+## Plugin Onboarding
 
 This document describes steps to onboard a new plugin to release workflow for continuous integration and testing.
 
@@ -22,7 +23,7 @@ Add the new plugin to the [opensearch-plugins meta](https://github.com/opensearc
 
 1. Update a [manifest](/manifests) for a particular release to include your plugin.  For example to be included in the 1.1.0 release, you would update [opensearch-1.1.0.yml](https://github.com/opensearch-project/opensearch-build/blob/opensearch-1.1.0/manifests/1.1.0/opensearch-1.1.0.yml). We require your plugin name, repository URL, and git ref that should be used. For unreleased versions this should be a branch in your repository.  Once a release is cut, these refs will be updated to build from a tag or specific commit hash.
 
-2. Create a `scripts/build.sh` if you have specific requirements that are not covered by the [default build.sh script](/scripts/default/opensearch/build.sh) and commit it to your repository.
+2. Create a `scripts/build.sh` if you have specific requirements that are not covered by the default build.sh script. See default build script for [OpenSearch plugins](./scripts/default/opensearch/build.sh) and [OpenSearch-Dashboard plugins](./scripts/default/opensearch-dashboards/build.sh) and commit it to your repository.
 
 3. Ensure your `build.sh` reads and passes along both `-Dbuild.snapshot=` and `-Dopensearch.version=` flags.  Snapshot builds should produce a -SNAPSHOT tagged artifact for example `opensearch-plugin-1.1.0.0-SNAPSHOT.zip` where a release build of the same component would produce `opensearch-plugin-1.1.0.0.zip`.
 
@@ -32,7 +33,7 @@ Add the new plugin to the [opensearch-plugins meta](https://github.com/opensearc
 
 6. Publish a PR to this repo including the updated manifest and the names of the artifacts being added.
 
-### Onboard to `test-workflow`
+### Onboard to Test Workflow
 
 1. Update the test configuration file (use 1.3.0 as an example), [opensearch-1.3.0-test.yml](https://github.com/opensearch-project/opensearch-build/blob/opensearch-1.3.0/manifests/1.3.0/opensearch-1.3.0-test.yml), for a particular release, to include your plugin. This test configuration defines full suite of tests - `integ`, `bwc`, that can be run on the plugin.
 
@@ -47,7 +48,11 @@ Add the new plugin to the [opensearch-plugins meta](https://github.com/opensearc
     1. It supports two test configs - `with-security` and `without-security`, which runs test with security plugin enabled and disabled respectively. Choose one or both depending on what your plugin integration tests support.
 
 
-## Onboarding to universal / 1-click release process:
+## Standalone Component Onboarding
+
+Standalone components are self-contained products that are published across diverse platforms, demanding their own release cycle that may or may not be dependent on OpenSearch or OpenSearch-Dashboard releases. Few examples of standalone components are OpenSearch clients (Java, JavaScript, Ruby, Go, Python, and Rust), data ingestion tools such as Data Prepper, and integration tools such as Logstash. See the process below to on-board to 1-click release process for standalone components. _Please note these components are not a part of the OpenSearch or OpenSearch-Dashboards distribution artifact._
+
+### Onboarding to universal / 1-click release process:
 
 This document describes steps to onboard a new component to universal or 1-click release process.
 
@@ -82,7 +87,7 @@ See https://github.com/opensearch-project/opensearch-build/issues/1234 for detai
 For example, this [PublishToNpm test](https://github.com/opensearch-project/opensearch-build-libraries/blob/main/tests/jenkins/TestPublishToNpm.groovy) uses [PublishToNpmLibTester](https://github.com/opensearch-project/opensearch-build-libraries/blob/main/tests/jenkins/lib-testers/PublishToNpmLibTester.groovy) with expected parameter that can be unique to your workflow. The assertions makes sure that calls to npm registry is made which is mandatory to release an artifact.
 
 
-## Onboard to PyPi GitHub Action release
+### Onboard to PyPi GitHub Action release
 
 Since PyPi has [announced](https://blog.pypi.org/posts/2023-05-23-removing-pgp/) the removal of the PGP signature, it is no longer necessary to use the Jenkins environment for releasing artifacts on PyPi. The main motive behind using Jenkins as the release environment was the ease of use of OpenSearch signing system.