POC: Concept/Solution to Automate the version increment to next development iteration.

[prudhvigodithi]

Is your feature request related to a problem? Please describe

Part of #1375

Describe the solution you'd like

Automate this version increment process across all plugin components, that increment’s the version, modifies the required files and raise a PR that awaits for plugin team approval, this way an engineer need not spend hours of time to increment the version for all plugin components.

Describe alternatives you've considered

No response

Additional context

No response

[prudhvigodithi]

Proposed Solution:

Automate this version increment process across all plugin components, that increment’s the version, modifies the required files and raise a PR that awaits for plugin team approval, this way an engineer need not spend hours of time to increment the version for all plugin components.

Solution Details:

The following details uses sql component, version increment process, to demonstrate the solution workflow.

• Each plugin will have a gradle property opensearch.version stored in gradle.properties file.
  Example opensearch.version=2.0.0-SNAPSHOT https://github.com/prudhvigodithi/sql/blob/main/gradle.properties

  With current/existing setup depending on OpenSearch version, the plugins version is inferred, this property is injected using gradle system properties.
  Moving forward this version will be inferred from plugin specific gradle property and rest of the flow just depend upon this opensearch.version gradle property.

  Note: This can be debated if opensearch.version should be passed from CI during distribution runtime or straight away use from plugin own gradle properties.
  Example:
  Existing flow -Dopensearch.version=$VERSION from build script is inferred from manifest
  Proposed Flow, to directly use project properties.

• Each Plugin, gradle build system will have two additional tasks which are responsible to increment the version and modify the required files.

  1. setVersion : This task will update the gradle property opensearch.version and updates the value in gradle.properties file.

  2. versionIncrement : This task is configurable and depends on the plugin requirement to modify any files where version is present and that needs to incremented, this task uses ant.replaceregexp to parse the required files that are added in include() section of the task. Example for sql

  For JSON files to increment the version, plugin teams can even include gradle node processes inside versionIncrement task, instead of RegEx parsing. However in the sql example i have used RegEx parsing to increment the version.
  https://ant.apache.org/manual/Tasks/replaceregexp.html

• The task setVersion is dependent on versionIncrement task, so when called ./gradlew setVersion -PnewVersion=2.1.0-SNAPSHOT (this task will be called using GitHub workflow explained below) the gradle property in gradle.propperties file gets updated to opensearch.version=2.1.0-SNAPSHOT and all include() section files will be replaced from 2.0.0 to 2.1.0 or 2.1.0.0 depending upon the value in the file.

• Using GitHub workflows the plugin specific branch is compared against the OpenSearch specific branch to check for OpenSearch version, if it’s different, i.e if OpenSearch is incremented and not the plugin, the workflow will auto raise a PR.
  Example:
  plugin 1.3 branch will look for OpenSearch repo 1.3 branch, checks if it has same version.
  plugin 2.x branch will look for OpenSearch repo 2.x branch, checks if it has same version.
  If the OpenSearch version is different (condition check done using github workflow) from what the plugin has the workflow will execute ./gradlew setVersion -PnewVersion=<OpenSearch_Version> which performs the actual version increment process and raises a PR.
  Sample PR’s: [AUTO] Increment version to 3.0.0-SNAPSHOT prudhvigodithi/sql#3 [AUTO] Version Increment to 3.0.0-SNAPSHOT prudhvigodithi/sql#2

  Note: This workflow can be scheduled using cron, on after release tag cut. This workflow can be part of each plugin .github/workflows/ or can be researched to be part of central build repo and target to create PR’s across all plugin components.

[bbarani]

@prudhvigodithi it looks like this issue is related to auto incrementing version as well.

[prudhvigodithi]

Closing this issue as the proposed initial POC testing is completed.