opensearch-project / common-utils Goto Github PK

Is your feature request related to a problem? Please describe.
To be consistent with every other library, rename to opensearch-common-utils.

This is a component issue for release 1.1.1.
Coming from release issue 1.1.1, release version 1.1.1. Please follow the following checklist.

You can find all the date in above issue

Preparation

• Assign this issue to a release owner.
• All the tasks in this issue have been reviewed by the release owner.
• Create, update, triage and label all features and issues targeted for this release with v1.1.1.

CI/CD

• All code changes for 1.1.1 are complete.
• Ensure working and passing CI.

Pre-Release

• Confirm that all changes for 1.1.1 have been merged.
• Complete integration and sanity tests, and update results in the comment, example.
• Find/fix bugs using latest tarball and docker image provided in meta issue.
• Completed release candidate testing build #TBD.
• All intermittent test failures have issues filed.

Release

• Complete documentation.
• Gather, review and publish release notes.
• Verify all issued labeled for this release are closed or labelled for the next release.

Post Release

• Create a release tag.
• Suggest improvements to this template.
• Conduct a retrospect, and publish its results.

Coming from opensearch-project/opensearch-plugins#64, default CI Java version to 11 (LTS), and run tests on 8, 14 and 17.

• Change the default Java version for CI in GitHub actions from 14/15 to 11 (LTS).
• Add Java 8, 14 (used before), and 17 (next LTS) to the CI matrix.
• Document Java versions in DEVELOPER_GUIDE.md.

Once the security plugin team updates the settings and paths to OpenSearch as part of security#11, the corresponding values have to be changed in common-utils.

Is your feature request related to a problem? Please describe.
opensearch-project/notifications#253

Adding the legacy classes/request/response/etc. needed for ISM to publish legacy notifications.

Coming from .github#13, standardize release branching to match what OpenSearch is doing.

1. Create a 1.0 branch for the OpenSearch 1.0 release, 1.x branch for next 1.1 release, and use main for 2.0 development. Make sure CI is enabled on those.
2. Update your release/branching documentation. If you don't have one, add a RELEASING.md that links to, or has content from .github/RELEASING.md. I did this in #32
3. Delete any merged/stale/develop/feature branches that are no longer in use.
4. Communicate any changes in process to your team.

Refer to release branching for more information.

Coming from opensearch-project/.github#21.

The correct copyright for open-source projects in opensearch-project is "Copyright OpenSearch Contributors". Please correct any places that say otherwise, especially where it says copyright Amazon. Make sure NOTICE.txt and README match. See opensearch-project/.github#24 for an example.

Is your feature request related to a problem? Please describe.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug
Bundle builds fail for 1.1 because changes for snapshots have not been back-ported, addition changes might be required please update 1.1 to whatever changes it should have for the 1.1 release.

In opensearch-project/OpenSearch#1276 we have benchmarked various JDKs and concluded that Java Runtime 17 gives a non-trivial performance boost. Therefore, coming from opensearch-project/opensearch-plugins#129, add support for JDK 17.

• Add JDK 17 to CI/CD, do not remove 11 and 14.
• Update DEVELOPER_GUIDE and any other notes on Java runtime compatibility.

Is your feature request related to a problem? Please describe.
Common Utils was stood up as an independent repo back in the days of ODFE. We have not revisited whether this still makes sense in an OpenSearch world :)

This issue is to evaluate if it makes sense to move common utils into core, and if so how/where.

Please note: Common Utils right now is a grab bag of different features and functions, many of which are marked deprecated. We'd want to make sure we were moving over only the things that made sense in a mindful manner, rather than a straight up "lift and shift" as is.

Require work:
Accounting and evaluation of what's currently in common utils.
For each item, determining the best location to move it into core (or into another plug in if applicable).

Is your feature request related to a problem? Please describe.

Build against alpha2 and release as -beta1.

Describe the solution you'd like

• Tag -beta1.

Description

Gradle project: Staging to add gradle tasks (setVersion and versionIncrement) that support version increment automation for supported versions and add/update gradle.properties file to the project.

Related META issue

Part of: opensearch-project/opensearch-build#1375
From solution: opensearch-project/opensearch-build#1375 (comment)

Current Behavior

Version Increment is a process that needs to be done for all plugin repos during and after a specific release.
This is time consuming and includes lot of manual human effort (that can lead to multiple errors) to go through each repo, check for previous merged PR and then create a version increment PR, allow plugin team to review, follow-up, update the PR with suggestions and then finally get merged for CI to run.

Expected Behavior

After every release expect to raise an [AUTO] PR that increments the version.
Sample automation version increment PR's: job-scheduler, common-utils, anomaly-detection, k-NN

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.

Implementation Changes:

Add gradle versionIncrement and setVersion tasks to the project.

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

gradle.properties : Contains gradle project properties that can be used by project during runtime, for version increment uses opensearch.version.

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.

Sample Implementation PR's: job-scheduler, common-utils, anomaly-detection, k-NN
More examples: opensearch-project/opensearch-build#1375 (comment)

Coming from opensearch-plugins#12, enable upgrade to OpenSearch, while supporting backward compatibility.

• Rename Namespaces (e.g. com.amazon.opendistroforelasticsearch to org.opensearch)
• Rename Classes, Methods, Variables
• Rename Remaining Identifiers (e.g. Opendistro to OpenSearch).
• Rename, and Backwards Compatibility for Rest APIs
• Rename, and Backwards Compatibility for Settings
• Rename, and Backwards Compatibility for Indices
• Run in a backwards compatible way on top of OpenSearch 1.0 that has joined an ES 7.10.x cluster
• Run in a backwards compatible way on top of OpenSearch 1.0 that has joined an ODFE 1.13.x cluster
• Drop in replacement for the Opendistro version 1.13 of the plugin

Security plugin (among other plugins) uses common_utils_version to get common-utils version dynamically based on opensearch-build's version.

opensearch_version = System.getProperty("opensearch.version", "2.2.0-SNAPSHOT")
version_tokens = opensearch_version.tokenize('-')
opensearch_build = version_tokens[0] + '.0'
common_utils_version = System.getProperty("common_utils.version", opensearch_build);

This is breaking the build because build.gradle is expecting common-utils to be available with version 2.2.0.0 but it is not out yet. This will block PRs from getting merged. A temporary solution to fix this is to hard-code common_utils_version property to latest stable version.

Proposed Solution:
Since hard-coding is not a good practice, and other plugins might be similarly affected by this issue, common-utils version should be added to version.properties file in core, to enable other plugins to easily access this dependency in build.gradle using something like:

testImplementation "org.opensearch:common-utils:${versions.common_utils}"

And common-utils can create a PR against core to update the core's version.properties each time there is a new release.

Is your feature request related to a problem? Please describe.
Coming from opensearch-project/opensearch-build#33

Describe the solution you'd like
Add Windows CI for this repo.

Please update the version consumed in main and 1.x branch according to OpenSearch main and 1.x respectively.

Coming from opensearch-project/project-meta#17

A Developer Certificate of Origin is required on commits in the OpenSearch-Project.

See doc.yml for an example workflow. Ensure CONTRIBUTING.md to has a section on the DCO per the project template.

• DCO Check Workflow
• CONTRIBUTING.md DCO Section

Coming from opensearch-build#567, release version 1.2. Please follow the following checklist.

Preparation

• Assign this issue to a release owner.
• Finalize scope and feature set and update the Public Roadmap.
• Create, update, triage and label all features and issues targeted for this release with v1.2.0.

CI/CD

• Increment version on main to 1.2.0.0.
• Ensure working and passing CI.
• Re(add) this repo to the manifest.

Pre-Release

• Branch and build from a 1.2 branch.
• Update your branch in the manifest.
• Feature complete, pencils down.
• Fix bugs that target this release.

Release

• Complete documentation.
• Gather, review and publish release notes.
• Verify all issued labeled for this release are closed or labelled for the next release.

Post Release

• Create a release tag.
• Suggest improvements to this template.
• Conduct a postmortem, and publish its results.

Because Apache Lucene 9 requires JDK 11 or newer, and coming from opensearch-project/opensearch-plugins#110, remove support for JDK 8.

• Remove JDK 8 from CI/CD, default to 11.
• Set Java source and target compatibility in all build.gradle files to JavaVersion.VERSION_11.
• Update DEVELOPER_GUIDE and remove any other mention of JDK 8.

This is a component issue for release 1.3.0.

Coming from opensearch-build#889, release version 1.3. Please follow the following checklist.

Preparation

• Assign this issue to a release owner.
• Finalize scope and feature set and update the Public Roadmap.
• Create, update, triage and label all features and issues targeted for this release with v1.3.0.

CI/CD

• Increment version on main to 1.3.0.0.
• Ensure working and passing CI.
• Re(add) this repo to the (if not exist) manifest.

Pre-Release

• Branch and build from a 1.3 branch.
• Update your branch in the manifest.
• Feature complete, pencils down.
• Fix bugs that target this release.

Release

• Complete documentation.
• Gather, review and publish release notes.
• Verify all issued labeled for this release are closed or labelled for the next release.

Post Release

• Create a release tag.
• Suggest improvements to this template.
• Conduct a postmortem, and publish its results.

Add code coverage badge and add the following for ci to pass, call it from GitHub Actions

codecov:
require_ci_to_pass: yes

coverage:
precision: 2
round: down
range: "75...100"
status:
project:
default:
target: 75% # the required coverage value
threshold: 1% # the leniency in hitting the target

Description

Ensure MAJOR_VERSION.x branch exists, the main branch acts as source of truth effectively working on 2 versions at the same time.

Related META issue

opensearch-project/opensearch-plugins#142

Current Behavior

Currently plugins follow a branching strategy where they work on main for the next development iteration, effectively working on 2 versions at the same time. This is not always true for all plugins, the release branch or branch pattern is not consistent, the lack of this standardization would limit multiple automation workflows and alignment with core repo. More details on META ISSUE

Proposed solution

Follow OpenSearch core branching. Create 1.x and 2.x branches, do not create 2.0 as a branch of main, instead create main -> 2.x -> 2.0. Maintain working CI for 3 releases at any given time.

Describe the bug

java.lang.ClassCastException: class org.opensearch.commons.notifications.action.SendNotificationRequest cannot be cast to class org.opensearch.commons.notifications.action.SendNotificationRequest (org.opensearch.commons.notifications.action.SendNotificationRequest is in unnamed module of loader java.net.FactoryURLClassLoader @1229a2b7; org.opensearch.commons.notifications.action.SendNotificationRequest is in unnamed module of loader java.net.FactoryURLClassLoader @28f9fedd)
        at org.opensearch.notifications.action.SendNotificationAction.doExecute(SendNotificationAction.kt:47) ~[?:?]
        at org.opensearch.action.support.TransportAction$RequestFilterChain.proceed(TransportAction.java:192) [opensearch-1.0.0-rc1.jar:1.0.0-rc1]
        at org.opensearch.indexmanagement.rollup.actionfilter.FieldCapsFilter.apply(FieldCapsFilter.kt:136) [opensearch-index-management-1.0.0.0-rc1.jar:1.0.0.0-rc1]
        at org.opensearch.action.support.TransportAction$RequestFilterChain.proceed(TransportAction.java:190) [opensearch-1.0.0-rc1.jar:1.0.0-rc1]
...

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Plugins
Please list all plugins currently enabled.

Screenshots
If applicable, add screenshots to help explain your problem.

Host/Environment (please complete the following information):

• OS: [e.g. iOS]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

Today all the packages in opensearch-project such as common-utils have the list of maintainers which is controlled by the MAINTAINERS.md file. We do have process defined by how we add people to the maintainers list depending upon their contributions and engagement in reviewing PRs, triaging issues etc.

However, this doesn’t necessarily imply that MAINTAINERS.md becomes the ever growing list of maintainers. We should come up with some unified process around cleaning up the list, based on the recency of the activities of the maintainers. Such as inactivity for 60 days.

Opening up this issue to collect more feedback/thoughts. Also to know, if we have already given some thought to it previously.

Coming from opensearch-project/opensearch-plugins#92.

Each plugin has a short descriptive text blurb that says what it does: this appears in plugin-descriptor.properties (OpenSearch plugins) or package.json (OpenSearch Dashboards plugins), as well as on the project website's "source" page and in the "About" section of every repo. These were created one-by-one over the years as plugins were created, so looking at them all together now it would be hard for somebody new to the project to use these to understand what the plugins do.

This is a component issue for 2.0.0 (GA).
Coming from opensearch-build 2086. Please follow the following checklist.
Please refer to the DATES in that post.

Preparation

• Assign this issue to a release owner.
• Finalize scope and feature set and update the Public Roadmap.
• All the tasks in this issue have been reviewed by the release owner.
• Create, update, triage and label all features and issues targeted for this release with v2.0.0.

CI/CD

• All code changes for 2.0.0 are complete.
• If this repo is core repo, use 2.0.0 version for your component; if this repo is plugin repo, use 2.0.0.0 version for your component. Qualifier should be empty '' see this issue for details: opensearch-project/opensearch-build#2078.
• Ensure working and passing CI.
• Check that this repo is included in the distribution manifest.

Pre-Release

• Update to the 2.0 release branch in the distribution manifest.
• Increment the version on the parent branch to the next development iteration.
• Gather, review and publish release notes following the rules and back port it to the release branch.git-release-notes may be used to generate release notes from your commit history.
• Confirm that all changes for 2.0.0 have been merged.

Release Testing

• Find/fix bugs using latest tarball and docker image provided in parent release issue and update the release notes if necessary.
• Code Complete: Test within the distribution, ensuring integration, backwards compatibility, and performance tests pass.
• Sanity Testing: Sanity testing and fixing of critical issues found.
• File issues for all intermittent test failures.

Release

• Complete documentation.
• Verify all issued labeled for this release are closed or labelled for the next release.

Post Release

• Prepare for an eventual security fix development iteration by incrementing the version on the release branch to the next eventual patch version.
• Add this repo to the manifest of the next eventual security patch version.
• Suggest improvements to this template.
• Conduct a retrospective, and publish its results.

Describe the bug

Coming from opensearch-project/opensearch-build#699

failureMessage	Required SHA-1: '/org/opensearch/common-utils/1.1.0.0/common-utils-1.1.0.0-sources.jar.sha1'
failureMessage	Required MD5: '/org/opensearch/common-utils/1.1.0.0/common-utils-1.1.0.0-sources.jar.md5'
failureMessage	Required SHA-1: '/org/opensearch/common-utils/1.1.0.0/common-utils-1.1.0.0-javadoc.jar.sha1'
failureMessage	Required MD5: '/org/opensearch/common-utils/1.1.0.0/common-utils-1.1.0.0-javadoc.jar.md5'
failureMessage	Required SHA-1: '/org/opensearch/common-utils/1.1.0.0/common-utils-1.1.0.0.pom.sha1'
failureMessage	Required MD5: '/org/opensearch/common-utils/1.1.0.0/common-utils-1.1.0.0.pom.md5'
failureMessage	Required SHA-1: '/org/opensearch/common-utils/1.1.0.0/common-utils-1.1.0.0.jar.sha1'
failureMessage	Required MD5: '/org/opensearch/common-utils/1.1.0.0/common-utils-1.1.0.0.jar.md5'

Bundle build invokes publishToMavenLocal and those hashes are missing.

Is your feature request related to a problem?
Humans have to remember to document features, or at least to open issues in documentation-website for new features/changes to be documented. This is a manual process, e.g. opensearch-project/OpenSearch#1711 (comment)

What solution would you like?
Add a workflow for creating issues in the documentation-website repo whenever a label needs-documentation is added on a PR. Refer: opensearch-project/OpenSearch#2929

What alternatives have you considered?
Create issues manually in the documentation-website whenever a feature needs to be documented.

Do you have any additional context?
Add any other context or screenshots about the feature request here.

Description

With existing setup the plugin jars are only published to maven repo, but not the generated plugin zips.

Related META issue

opensearch-project/opensearch-build#1916

Current Behavior

Existing all maven publications target the jar files to publish to maven, but not the generated distribution zips.

Expected Behavior

Along with plugin jars, plugin zips should also be published to maven repo with right maven coordinates, so user can download these plugins using dependancy model.

Steps To Reproduce

1. Run the gradle assemble task that outputs jar and zips.
2. Using build setup the jars are published to local staging maven repo.
3. Zip's are just added to distribution's folder during build runtime.
4. Finally once build is done, just the jar files are added to local maven repo and updates to the manifest file, but not the zips.

Proposed solution

A custom gradle plugin solution that can create the publication task for the zips to get published to local staging maven repo with right maven coordinates.
Add/Configure the custom gradle plugin openseearch.pluginzip to the gradle project and test the generated plugin zip's to upload to local maven repo.
More details on how to use the Plugin:
https://github.com/opensearch-project/opensearch-plugins/blob/main/BUILDING.md#opensearchpluginzip

This is a component issue for 2.1.0.
Coming from opensearch-build#1818. Please follow the following checklist.
Please refer to the DATES in that post.

Preparation

• Assign this issue to a release owner.
• Finalize scope and feature set and update the Public Roadmap.
• All the tasks in this issue have been reviewed by the release owner.
• Create, update, triage and label all features and issues targeted for this release with v2.1.0.

CI/CD

• All code changes for 2.1.0 are complete.
• Ensure working and passing CI.
• Check that this repo is included in the distribution manifest.

Pre-Release

• Update to the 2.1.0 release branch in the distribution manifest.
• Increment the version on the parent branch to the next development iteration.
• Gather, review and publish release notes following the rules and back port it to the release branch.git-release-notes may be used to generate release notes from your commit history.
• Confirm that all changes for 2.1.0 have been merged.
• Add this repo to the manifest for the next developer iteration.

Release Testing

• Find/fix bugs using latest tarball and docker image provided in parent release issue and update the release notes if necessary.
• Code Complete: Test within the distribution, ensuring integration, backwards compatibility, and performance tests pass.
• Sanity Testing: Sanity testing and fixing of critical issues found.
• File issues for all intermittent test failures.

Release

• Complete documentation.
• Verify all issued labeled for this release are closed or labelled for the next release.

Post Release

• Prepare for an eventual security fix development iteration by incrementing the version on the release branch to the next eventual patch version.
• Add this repo to the manifest of the next eventual security patch version.
• Suggest improvements to this template.
• Conduct a retrospective, and publish its results.

Coming from opensearch-project/opensearch-plugins#132, remove support for JDK 14.

In OpenSearch 2.0 we are building the complete distribution and every component with JDK 11, and testing and bundling JDK 17. Support for JDK 14, 15 and other non-LTS versions can be dropped. Remove building and testing with these JDKs from CI.

See https://opensearch.org/blog/technical-post/2022/03/opensearch-java-runtime/ for more information.

We are coming from this issue: opensearch-project/opensearch-build#2078 in your 2.0 branch.

Note: This needs to be completed before 05/17 which is feature freeze day for 2.0.0-GA.

1. If you have OpenSearch plugin in your repo, make sure your build.gradle remove rc1 reference, leave as "".

opensearch_version = System.getProperty("opensearch.version", "2.0.0-SNAPSHOT")
buildVersionQualifier = System.getProperty("build.version_qualifier", "")

2. If you have OpenSearch-Dashboards plugin in your repo, make sure your package.json remove rc1 reference, leave as 2.0.0.0.

"version": "2.0.0.0",

3. If you have any .github/workflows contains hardcode rc1 reference, please remove.

Thanks.

Is your feature request related to a problem? Please describe.
The OpenSearch Plugins are still built using Gradle 6.6.x whereas the Gradle release train has moved to 7.x already. The OpenSearch core is about to be switched to Gradle 7.3 (see please opensearch-project/OpenSearch#1609), it would make sense to switch all plugins to Gradle 7.3 as well.

Describe the solution you'd like
Update Gradle to 7.3

Describe alternatives you've considered (Optional)
N/A

Additional context
See please opensearch-project/OpenSearch#1246 and opensearch-project/opensearch-plugins#107

Coming from opensearch-project/opensearch-build#1632, add support for -Dbuild.version_qualifier=.

The distribution build process now supports passing additional optional qualifiers other than the 3 digit versions, e.g. 2.0.0-alpha1. Add the ability to pass additional qualifier to build scripts, and generate artifacts with a version that includes the qualifier.

Coming from opensearch-project/opensearch-plugins#45, use SNAPSHOT Maven dependencies from aws.oss.sonatype.org. See https://github.com/opensearch-project/opensearch-plugins/blob/main/BUILDING.md#building-within-the-opensearch-build-system for details.

Is your feature request related to a problem? Please describe.
Coming from opensearch-project/opensearch-build#38

Describe the solution you'd like
Add MacOS CI for this repo.

Describe the bug

The maven artifacts published don't match maven repo layout that can be copied into ~/.m2. Likely caused by #80. This will break integration tests.

Before

$ find ~/.m2/repository/org/opensearch/common-utils/
/home/ubuntu/.m2/repository/org/opensearch/common-utils/
/home/ubuntu/.m2/repository/org/opensearch/common-utils/maven-metadata-local.xml
/home/ubuntu/.m2/repository/org/opensearch/common-utils/1.1.0.0
/home/ubuntu/.m2/repository/org/opensearch/common-utils/1.1.0.0/common-utils-1.1.0.0-javadoc.jar
/home/ubuntu/.m2/repository/org/opensearch/common-utils/1.1.0.0/common-utils-1.1.0.0-sources.jar
/home/ubuntu/.m2/repository/org/opensearch/common-utils/1.1.0.0/common-utils-1.1.0.0.pom
/home/ubuntu/.m2/repository/org/opensearch/common-utils/1.1.0.0/common-utils-1.1.0.0.jar

After

./build.sh manifests/1.2.0/opensearch-1.2.0.yml

$ find builds/maven/org/opensearch/common-utils/
builds/maven/org/opensearch/common-utils/
builds/maven/org/opensearch/common-utils/common-utils-1.2.0.0-sources.jar.sha512
builds/maven/org/opensearch/common-utils/common-utils-1.2.0.0.jar.sha256
builds/maven/org/opensearch/common-utils/common-utils-1.2.0.0-javadoc.jar.sha256
builds/maven/org/opensearch/common-utils/common-utils-1.2.0.0-javadoc.jar.sha512
builds/maven/org/opensearch/common-utils/common-utils-1.2.0.0-sources.jar.md5
builds/maven/org/opensearch/common-utils/common-utils-1.2.0.0.jar.sha512
builds/maven/org/opensearch/common-utils/common-utils-1.2.0.0-sources.jar.sha1
builds/maven/org/opensearch/common-utils/common-utils-1.2.0.0.jar.sha1
builds/maven/org/opensearch/common-utils/common-utils-1.2.0.0-javadoc.jar.sha1
builds/maven/org/opensearch/common-utils/common-utils-1.2.0.0.jar
builds/maven/org/opensearch/common-utils/common-utils-1.2.0.0-sources.jar
builds/maven/org/opensearch/common-utils/common-utils-1.2.0.0.jar.md5
builds/maven/org/opensearch/common-utils/common-utils-1.2.0.0-sources.jar.sha256
builds/maven/org/opensearch/common-utils/common-utils-1.2.0.0-javadoc.jar
builds/maven/org/opensearch/common-utils/common-utils-1.2.0.0-javadoc.jar.md5

Describe the bug

https://github.com/opensearch-project/common-utils/actions/runs/2000270385

Run tibdex/[email protected]
Error: Error: Input required and not supplied: app_id

Describe the bug
When I create a new issue, it still has a beta label, which has long shipped.

Describe the bug

Coming from opensearch-project/opensearch-build#179, the build with -Dbuild.snapshot=true doesn't produce snapshot outputs.

To Reproduce

./gradlew publishToMavenLoacal --no-daemon --refresh-dependencies -DskipTests=true -Dopensearch.version=1.0.0-SNAPSHOT -Dbuild.snapshot=true

Creates ~/.m2/repository/org/opensearch/common-utils/1.0.0.0.

Expected behavior

Expected common-utils/1.0.0-SNAPSHOT.

This is a component issue for release 2.0.0 (RC1).

Coming from opensearch-project/opensearch-build#1624, please refer to the dates in that post.

Please also follow the following checklist.

You can find all the date in above issue

Preparation

• Assign this issue to a release owner.
• Finalize scope and feature set and update the Public Roadmap.
• All the tasks in this issue have been reviewed by the release owner.
• Create, update, triage and label all features and issues targeted for this release with v2.0.0.

CI/CD

• All code changes for 2.0.0 are complete.
• Ensure working and passing CI.
• Re(add) this repo to the (if not exist) opensearch input manifest.

Pre-Release

• Update your branch in the opensearch input manifest.
• Confirm that all changes for 2.0.0 have been merged.
• Complete integration tests, and update results in the comment, example.
• Find/fix bugs using latest tarball and docker image provided in meta issue.
• Completed release candidate testing build #TBD.
• All intermittent test failures have issues filed.

Release

• Complete documentation.
• Gather, review and publish release notes.
• Verify all issued labeled for this release are closed or labelled for the next release.

Post Release

• Create a release tag.
• Suggest improvements to this template.
• Conduct a retrospect, and publish its results.

This component should be upgraded to gradle 7.0+ to unblock 1.3.0 distribution builds, which are currently broken. More details in tracking ticket in opensearch-build: opensearch-project/opensearch-build#1587

Coming from meta issue opensearch-project/opensearch-plugins#108:

• Add auto-backport PR creation Github action to make sure all the PRs are backported for a particular release.
• Add auto-delete for merged auto-backport PRs to clean up the branches created during auto-backport.
• Add documentation for the same.

Related documentation: https://github.com/opensearch-project/opensearch-plugins/blob/main/BACKPORT.md

Description

JCenter has been turned off and should be removed as a referenced repository.

Please Remove any direct dependency on jcenter() within a repositories block in gradle files.

Related: opensearch-project/opensearch-build#1456

Is your feature request related to a problem? Please describe.
opensearch-project/opensearch-plugins#73

Describe the solution you'd like
Please update the CI workflow to generate code coverage and upload it to Codecov, so that the code coverage information is shown in the Codecov dashboard (https://app.codecov.io/gh/opensearch-project/)

Describe alternatives you've considered
N/A

Additional context
The guide for reporting the code coverage is located here. (https://github.com/opensearch-project/opensearch-plugins/blob/main/TESTING.md#code-coverage-reporting)

Is your feature request related to a problem? Please describe.
It appears that we have several instances of ODFERestTestCase implementations across plugin repos:

1. https://github.com/opensearch-project/k-NN/blob/main/src/test/java/org/opensearch/knn/ODFERestTestCase.java
2. https://github.com/opensearch-project/anomaly-detection/blob/main/src/test/java/org/opensearch/ad/ODFERestTestCase.java
3. https://github.com/opensearch-project/alerting/blob/11aafbe26189a474349d24c161ca956c044c7b63/alerting/src/test/kotlin/org/opensearch/alerting/ODFERestTestCase.kt

This base test class is meant to ensure ODFE compatibility. Each implementations seems slightly different. We had a test failure related to this case here: opensearch-project/k-NN#214. Given all of this, it appears that this class is a good candidate to move to common-utils.

Describe the bug
This repo lacks a description

Other plugins installed
N/a

To Reproduce
Steps to reproduce the behavior:

1. Go to https://github.com/opensearch-project/common-utils/ in any browser
2. Look to the right, a little down from the top of the page
3. Instead of a user friendly description, you'll see something like this:

Expected behavior
To see a one-line description of what this repo does.

Screenshots
See above

As part of v2.0 release, mapping types are getting removed from OpenSearch engine. Below are the changes in the opensearch-engine.

• Removal of type from rest end-points
• Removal of include_type_name parameter from API requests.

As part of this issue, please verify if type removal change on OpenSearch engine impacts this repository. If yes, then please remove the type references/usage from this plugin.

Top level changes are captured in gist below:
https://gist.github.com/dreamer-89/d76eaf639171e8ab32fa7f8b9d6c93d3

For more detailed changes, please check meta issue below:
Related: OpenSearch-engine meta issue

Describe the bug

org.opensearch.commons.rest.TrustStoreTest is failing on Windows on main

To Reproduce

./gradlew test

Host/Environment (please complete the following information):
MINGW64_NT-10.0-17763 EC2AMAZ-4PA8CKB 3.1.7-340.x86_64 2021-10-12 16:29 UTC x86_64 Msys

Additional context
Coming from opensearch-project/opensearch-build#33

org.opentest4j.AssertionFailedError: expected: <true> but was: <false>
	at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
	at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:40)
	at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:35)
	at org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:162)
	at org.opensearch.commons.rest.TrustStoreTest.testCreate(TrustStoreTest.java:44)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:688)
	at org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
	at org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
	at org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
	at org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
	at org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
	at org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
	at org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
	at org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
	at org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
	at org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
	at org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
	at org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
	at org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
	at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:210)
	at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
	at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:206)
	at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:131)
	at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:65)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:139)
	at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:129)
	at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:127)
	at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:126)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:84)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
	at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:38)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:143)
	at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:129)
	at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:127)
	at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:126)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:84)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
	at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:38)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:143)
	at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:129)
	at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:127)
	at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:126)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:84)
	at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.submit(SameThreadHierarchicalTestExecutorService.java:32)
	at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor.execute(HierarchicalTestExecutor.java:57)
	at org.junit.platform.engine.support.hierarchical.HierarchicalTestEngine.execute(HierarchicalTestEngine.java:51)
	at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:248)
	at org.junit.platform.launcher.core.DefaultLauncher.lambda$execute$5(DefaultLauncher.java:211)
	at org.junit.platform.launcher.core.DefaultLauncher.withInterceptedStreams(DefaultLauncher.java:226)
	at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:199)
	at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:132)
	at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
	at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatformTestClassProcessor.java:79)
	at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor.stop(JUnitPlatformTestClassProcessor.java:75)
	at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.stop(SuiteTestClassProcessor.java:61)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
	at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33)
	at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
	at com.sun.proxy.$Proxy5.stop(Unknown Source)
	at org.gradle.api.internal.tasks.testing.worker.TestWorker.stop(TestWorker.java:132)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
	at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:182)
	at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:164)
	at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:413)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
	at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
	at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
	at java.base/java.lang.Thread.run(Thread.java:832)