Fix backport delete action; Adding Badges for Build and Link Checker (…

…opensearch-project#54)

* moving PR template to .github folder

Signed-off-by: Mark Cohen <[email protected]>

* moving PR template to .github folder

Signed-off-by: Mark Cohen <[email protected]>

* changed backport/ to backport- to match the actual branches created by the backport workflow

Signed-off-by: Mark Cohen <[email protected]>

* adding badges for build and link checker

Signed-off-by: Mark Cohen <[email protected]>

* updated test-and-build.yml to use checkout v2.5 to update to node 16 according to deprecation warnings

Signed-off-by: Mark Cohen <[email protected]>

* added .0 on the end of v2.5

Signed-off-by: Mark Cohen <[email protected]>

* changed checkout to v3

Signed-off-by: Mark Cohen <[email protected]>

* fixing links and adding SECURITY,md

Signed-off-by: Mark Cohen <[email protected]>

* adding .codecov.yml

Signed-off-by: Mark Cohen <[email protected]>

* moved .github/workflows/.codecov.yml -> .github/.codecov.yml

Signed-off-by: Mark Cohen <[email protected]>

* cleaning up README

Signed-off-by: Mark Cohen <[email protected]>

* adding workflow for release notes

Signed-off-by: Mark Cohen <[email protected]>

Signed-off-by: Mark Cohen <[email protected]>

.github/.codecov.yml

@@ -0,0 +1,7 @@
+# https://docs.codecov.com/docs/codecov-yaml
+coverage:
+  status:
+    project:
+      default:
+        # https://docs.codecov.com/docs/commit-status#target
+        target: auto  # coverage must be equal or above the previous commit

.github/workflows/delete-backport-branch.yml

@@ -7,7 +7,7 @@ on:
 jobs:
   delete-branch:
     runs-on: ubuntu-latest
-    if: startsWith(github.event.pull_request.head.ref,'backport/')
+    if: startsWith(github.event.pull_request.head.ref,'backport-')
     steps:
       - name: Delete merged branch
         uses: SvanBoxel/delete-merged-branch@main

.github/workflows/draft-release-notes-workflow.yml

@@ -0,0 +1,20 @@
+name: Release Drafter
+
+on:
+  push:
+    branches:
+      - main
+
+jobs:
+  update_release_draft:
+    name: Update draft release notes
+    runs-on: ubuntu-latest
+    steps:
+      - name: Update draft release notes
+        uses: release-drafter/release-drafter@v5
+        with:
+          config-name: draft-release-notes-config.yml
+          name: Version (set here)
+          tag: (None)
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/link-checker.yml

@@ -10,7 +10,7 @@ jobs:
     runs-on: ubuntu-latest
 
     steps:
-      - uses: actions/checkout@v2
+      - uses: actions/checkout@v3
       - name: lychee Link Checker
         id: lychee
         uses: lycheeverse/lychee-action@master

.github/workflows/test-and-build.yml

@@ -20,12 +20,12 @@ jobs:
         run: git config --global core.longpaths true
 
       - name: Checkout Dashboards Search Relevance plugin
-        uses: actions/checkout@v2
+        uses: actions/checkout@v3
         with:
           path: dashboards-search-relevance
 
       - name: Checkout OpenSearch Dashboards
-        uses: actions/checkout@v2
+        uses: actions/checkout@v3
         with:
           repository: opensearch-project/OpenSearch-Dashboards
           ref: ${{ env.OPENSEARCH_VERSION }}

MAINTAINERS.md

@@ -78,7 +78,7 @@ Add integration checks that validate pull requests and pushes to ease the burden
 
 #### Developer Certificate of Origin Workflow
 
-Validates pull requests commits are all signed with DCO, [dco.yml](./workflow/dco.yml).  Example [pull request](https://github.com/opensearch-project/opensearch-ci/pull/16).
+Validates pull requests commits are all signed with DCO, [dco.yml](./.github/workflows/dco.yml).  Example [pull request](https://github.com/opensearch-project/opensearch-ci/pull/16).
 
 ### Use Semver
 

README.md

@@ -1,5 +1,9 @@
 ![OpenSearch Project](OpenSearch.svg)
+
 # Search Relevance Tools
+[![Link Checker](https://github.com/opensearch-project/dashboards-search-relevance/actions/workflows/link-checker.yml/badge.svg?branch=main)](https://github.com/opensearch-project/dashboards-search-relevance/actions/workflows/link-checker.yml)
+
+[![Build Search Relevance Plugin](https://github.com/opensearch-project/dashboards-search-relevance/actions/workflows/test-and-build.yml/badge.svg)](https://github.com/opensearch-project/dashboards-search-relevance/actions/workflows/test-and-build.yml)
 
 ## Summary
 In search applications, tuning relevance is a constant, iterative exercise to bring the right search results to your end users. The tooling in this repository aims to help the search relevance engineer and business user create the best search experience possible for application users without hiding internals from engineers who want to go deep into the details.
@@ -8,10 +12,11 @@ In search applications, tuning relevance is a constant, iterative exercise to br
 ## Search Comparison UI
 The first release in this plugin will include an experimental feature to allow users to enter a plain text search query, substitute that query into two different QueryDSLs and compare the results side by side.
 
-### Repository Checks
 # Security
+See [SECURITY](SECURITY.md) for more information.
 
-See [CONTRIBUTING](CONTRIBUTING.md#security-issue-notifications) for more information.
+# Contributing
+See [CONTRIBUTING](CONTRIBUTING.md) for more information.
 
 # License
 

RELEASING.md

@@ -1,107 +1 @@
-- [Overview](#overview)
-- [Branching](#branching)
-  - [OpenSearch Branching](#opensearch-branching)
-  - [Plugin Branching](#plugin-branching)
-  - [Feature Branches](#feature-branches)
-- [Versioning](#versioning)
-  - [Version Numbers](#version-numbers)
-  - [Incrementing Versions](#incrementing-versions)
-- [Tagging](#tagging)
-- [Release Labels](#release-labels)
-- [Releasing](#releasing)
-- [Backporting](#backporting)
-
-## Overview
-
-This document explains the release strategy for artifacts in this organization.
-
-## Branching
-
-Projects create a new branch when they need to start working on 2 separate versions of the product, with the `main` branch being the furthermost release. 
-
-### OpenSearch Branching
-
-[OpenSearch](https://github.com/opensearch-project/OpenSearch) typically tracks 3 releases in parallel. For example, given the last major release of 1.0, OpenSearch in this organization maintains the following active branches.
-
-* **main**: The _next major_ release, currently 2.0. This is the branch where all merges take place, and code moves fast.
-* **1.x**: The _next minor_ release, currently 1.1. Once a change is merged into `main`, decide whether to backport it to `1.x`.
-* **1.0**: The _current_ release, currently 1.0. In between minor releases, only hotfixes (e.g. security) are backported to `1.0`. The next release out of this branch will be 1.0.1.
-
-Label PRs with the next major version label (e.g. `2.0.0`) and merge changes into `main`. Label PRs that you believe need to be backported as `1.x` and `1.0`. Backport PRs by checking out the versioned branch, cherry-pick changes and open a PR against each target backport branch.
-
-### Plugin Branching
-
-Plugins are bundled and shiped together along with OpenSearch for every release. Plugin branching follows OpenSearch core branching that will allow working on 3 releases at the same time.
-
-### Feature Branches
-
-Do not creating branches in the upstream repo, use your fork, for the exception of long lasting feature branches that require active collaboration from multiple developers. Name feature branches `feature/<thing>`. Once the work is merged to `main`, please make sure to delete the feature branch.
-
-## Versioning
-
-OpenSearch versioning [follows semver](https://opensearch.org/blog/technical-post/2021/08/what-is-semver/). 
-
-### Version Numbers
-
-The build number of the engine is 3-digit `major.minor.patch` (e.g. `1.1.0`), while plugins use 4 digits (`1.1.0.45`). See [OpenSearch#1093](https://github.com/opensearch-project/OpenSearch/issues/1093) for a proposal to remove this difference. 
-
-### Incrementing Versions
-
-Versions are incremented as soon as development starts on a given version to avoid confusion. In the examples above versions are as follows.
-
-* OpenSearch: `main` = 2.0.0, `1.x` = 1.1.0, and `1.0` = 1.0.0
-* job-scheduler: `main` = 1.1.0.0, `1.0` = 1.0.0.0
-
-## Tagging
-
-Create tags after a release that match the version number, `major.minor.patch`, without a `v` prefix.
-
-* [OpenSearch tags](https://github.com/opensearch-project/OpenSearch/tags): [1.0.0](https://github.com/opensearch-project/OpenSearch/releases/tag/1.0.0)
-* [job-scheduler tags](https://github.com/opensearch-project/job-scheduler/tags): [1.0.0.0](https://github.com/opensearch-project/job-scheduler/releases/tag/1.0.0.0)
-
-For a discussion on whether to add a prefixing `v` to release tags, see [#35](https://github.com/opensearch-project/.github/issues/35).  
-
-## Release Labels
-
-Repositories create consistent release labels, such as `v1.0.0`, `v1.1.0` and `v2.0.0`, as well as `patch` and `backport`. Use release labels to target an issue or a PR for a given release. See [MAINTAINERS](MAINTAINERS.md#triage-open-issues) for more information on triaging issues.
-
-## Releasing
-
-The OpenSearch release process is centralized.
-
-1. Two candidate bundle builds for OpenSearch and OpenSearch Dashboards, produced by [bundle-workflow](https://github.com/opensearch-project/opensearch-build/blob/main/bundle-workflow/README.md), are chosen as release candidates. Those artifacts have successful end-to-end integration, backwards-compatibility and performance tests, and are signed.
-2. Staged maven artifacts are promoted to Maven Central.
-3. Bundles and -min artifacts are published to [opensearch.org](https://opensearch.org/downloads.html).
-
-## Backporting
-
-This project follows [semantic versioning](https://semver.org/spec/v2.0.0.html). Backwards-incompatible changes always result in a new major version and will __never__ be backported. Small improvements and features will be backported to a new minor version (e.g. `1.1`). Security fixes will be backported to a new patch version (e.g. `1.0.1`).
-
-Here are the commands we typically run to backport changes to release branches:
-
-1. Checkout the target release branch and pull the latest changes from `upstream`. In the examples below, our target release branch is `1.x`.
-
-```
-git checkout 1.x
-git pull upstream 1.x
-```
-
-2. Create a local branch for the backport. A convenient naming convention is _backport-\[PR-id\]-\[target-release-branch\]_.
-
-```
-git checkout -b backport-pr-xyz-1.x
-```
-
-3. Cherry-pick the commit to backport. Remember to include [DCO signoff](CONTRIBUTING.md#developer-certificate-of-origin).
-
-```
-git cherry-pick <commit-id> -s
-```
-
-4. Push the local branch to your fork.
-
-```
-git push origin backport-pr-xyz-1.x
-```
-
-5. Create a pull request for the change.
+This project follows the [OpenSearch release process](https://github.com/opensearch-project/.github/blob/main/RELEASING.md).

SECURITY.md

@@ -0,0 +1,3 @@
+## Reporting a Vulnerability
+
+If you discover a potential security issue in this project we ask that you notify AWS/Amazon Security via our [vulnerability reporting page](http://aws.amazon.com/security/vulnerability-reporting/) or directly via email to [email protected]. Please do **not** create a public GitHub issue.