Skip to content

Commit d708725

Browse files
navneet1vnavneet1v
authored
[#1]Fix CI and Link Checker github workflows (#3)
* Added .md files for fixing the link checker workflow. * Added flags for fixing spotless checks in Java 17 version. Signed-off-by: Navneet Verma <[email protected]> Signed-off-by: Navneet Verma <[email protected]>
1 parent 1d68b10 commit d708725

File tree

6 files changed

+147
-1
lines changed

6 files changed

+147
-1
lines changed

Diff for: ‎.github/workflows/CI.yml

+1-1
Original file line numberDiff line numberDiff line change
@@ -41,7 +41,7 @@ jobs:
4141
matrix:
4242
java: [11, 17]
4343

44-
name: Build and Test neural-search Plugin
44+
name: Pre-commit neural-search Plugin
4545
runs-on: ubuntu-latest
4646

4747
steps:

Diff for: ‎ADMINS.md

+27
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
## Overview
2+
3+
This document explains who the admins are (see below), what they do in this repo, and how they should be doing it. If you're interested in becoming a maintainer, see [MAINTAINERS](MAINTAINERS.md). If you're interested in contributing, see [CONTRIBUTING](CONTRIBUTING.md).
4+
5+
## Current Admins
6+
7+
| Admin | GitHub ID | Affiliation |
8+
| --------------- | --------------------------------------- | ----------- |
9+
| Charlotte | [CEHENKLE](https://github.com/CEHENKLE) | Amazon |
10+
11+
## Admin Responsibilities
12+
13+
As an admin you own stewartship of the repository and its settings. Admins have [admin-level permissions on a repository](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-permission-levels-for-an-organization). Use those privileges to serve the community and protect the repository as follows.
14+
15+
### Prioritize Security
16+
17+
Security is your number one priority. Manage security keys and safeguard access to the repository.
18+
19+
Note that this repository is monitored and supported 24/7 by Amazon Security, see [Reporting a Vulnerability](SECURITY.md) for details.
20+
21+
### Enforce Code of Conduct
22+
23+
Act on [CODE_OF_CONDUCT](CODE_OF_CONDUCT.md) violations by revoking access, and blocking malicious actors.
24+
25+
### Adopt Organizational Best Practices
26+
27+
Adopt organizational best practices, work in the open, and collaborate with other admins by opening issues before making process changes. Prefer consistency, and avoid diverging from practices in the opensearch-project organization.

Diff for: ‎MAINTAINERS.md

+71
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,71 @@
1+
- [Overview](#overview)
2+
- [Current Maintainers](#current-maintainers)
3+
- [Maintainer Responsibilities](#maintainer-responsibilities)
4+
- [Uphold Code of Conduct](#uphold-code-of-conduct)
5+
- [Prioritize Security](#prioritize-security)
6+
- [Review Pull Requests](#review-pull-requests)
7+
- [Triage Open Issues](#triage-open-issues)
8+
- [Be Responsive](#be-responsive)
9+
- [Maintain Overall Health of the Repo](#maintain-overall-health-of-the-repo)
10+
- [Use Semver](#use-semver)
11+
- [Release Frequently](#release-frequently)
12+
- [Promote Other Maintainers](#promote-other-maintainers)
13+
14+
## Overview
15+
16+
This document explains who the maintainers are (see below), what they do in this repo, and how they should be doing it. If you're interested in contributing, see [CONTRIBUTING](CONTRIBUTING.md).
17+
18+
## Current Maintainers
19+
20+
| Maintainer | GitHub ID | Affiliation |
21+
|------------------------| --------------------------------------- | ----------- |
22+
| Vamshi Vijay Nakkirtha | [vamshin](https://github.com/vamshin) | Amazon |
23+
| Sean Zheng | [sean-zheng-amazon](https://github.com/sean-zheng-amazon) | Amazon |
24+
| Jack Mazanec | [jmazanec15](https://github.com/jmazanec15) | Amazon |
25+
26+
27+
## Maintainer Responsibilities
28+
29+
Maintainers are active and visible members of the community, and have [maintain-level permissions on a repository](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-permission-levels-for-an-organization). Use those privileges to serve the community and evolve code as follows.
30+
31+
### Uphold Code of Conduct
32+
33+
Model the behavior set forward by the [Code of Conduct](CODE_OF_CONDUCT.md) and raise any violations to other maintainers and admins.
34+
35+
### Prioritize Security
36+
37+
Security is your number one priority. Maintainer's Github keys must be password protected securely and any reported security vulnerabilities are addressed before features or bugs.
38+
39+
Note that this repository is monitored and supported 24/7 by Amazon Security, see [Reporting a Vulnerability](SECURITY.md) for details.
40+
41+
### Review Pull Requests
42+
43+
Review pull requests regularly, comment, suggest, reject, merge and close. Accept only high quality pull-requests. Provide code reviews and guidance on incomming pull requests. Don't let PRs be stale and do your best to be helpful to contributors.
44+
45+
### Triage Open Issues
46+
47+
Manage labels, review issues regularly, and triage by labelling them.
48+
49+
All repositories in this organization have a standard set of labels, including `bug`, `documentation`, `duplicate`, `enhancement`, `good first issue`, `help wanted`, `blocker`, `invalid`, `question`, `wontfix`, and `untriaged`, along with release labels, such as `v1.0.0`, `v1.1.0`, `v2.0.0`, `patch`, and `backport`.
50+
51+
Use labels to target an issue or a PR for a given release, add `help wanted` to good issues for new community members, and `blocker` for issues that scare you or need immediate attention. Request for more information from a submitter if an issue is not clear. Create new labels as needed by the project.
52+
53+
### Be Responsive
54+
55+
Respond to enhancement requests, and forum posts. Allocate time to reviewing and commenting on issues and conversations as they come in.
56+
57+
### Maintain Overall Health of the Repo
58+
59+
Keep the `main` branch at production quality at all times. Backport features as needed. Cut release branches and tags to enable future patches.
60+
61+
### Use Semver
62+
63+
Use and enforce [semantic versioning](https://semver.org/) and do not let breaking changes be made outside of major releases.
64+
65+
### Release Frequently
66+
67+
Make frequent project releases to the community.
68+
69+
### Promote Other Maintainers
70+
71+
Assist, add, and remove [MAINTAINERS](MAINTAINERS.md). Exercise good judgement, and propose high quality contributors to become co-maintainers.

Diff for: ‎RELEASING.md

+34
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,34 @@
1+
- [Overview](#overview)
2+
- [Branching](#branching)
3+
- [Release Branching](#release-branching)
4+
- [Feature Branches](#feature-branches)
5+
- [Release Labels](#release-labels)
6+
- [Releasing](#releasing)
7+
8+
## Overview
9+
10+
This document explains the release strategy for artifacts in this organization.
11+
12+
## Branching
13+
14+
### Release Branching
15+
16+
Given the current major release of 1.0, projects in this organization maintain the following active branches.
17+
18+
* **main**: The next _major_ release. This is the branch where all merges take place and code moves fast.
19+
* **1.x**: The next _minor_ release. Once a change is merged into `main`, decide whether to backport it to `1.x`.
20+
* **1.0**: The _current_ release. In between minor releases, only hotfixes (e.g. security) are backported to `1.0`.
21+
22+
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.
23+
24+
### Feature Branches
25+
26+
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.
27+
28+
## Release Labels
29+
30+
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.
31+
32+
## Releasing
33+
34+
The release process is standard across repositories in this org and is run by a release manager volunteering from amongst [MAINTAINERS](MAINTAINERS.md).

Diff for: ‎SECURITY.md

+3
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,3 @@
1+
## Reporting a Vulnerability
2+
3+
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.

Diff for: ‎gradle.properties

+11
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,11 @@
1+
#
2+
# Copyright OpenSearch Contributors
3+
# SPDX-License-Identifier: Apache-2.0
4+
#
5+
6+
# For fixing Spotless check with Java 17
7+
org.gradle.jvmargs=--add-exports jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED \
8+
--add-exports jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED \
9+
--add-exports jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED \
10+
--add-exports jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED \
11+
--add-exports jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED

0 commit comments

Comments
 (0)