diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 737bb2284d..7a5b48918c 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -8,17 +8,6 @@ - [General Guidelines](#general-guidelines) - [Correcting Mistakes](#correcting-mistakes) - [Retrospectives](#retrospectives) -- [ZenHub Process Workflow](#zenhub-process-workflow) - - [What is ZenHub?](#what-is-zenhub) - - [Setting up ZenHub](#setting-up-zenhub) - - [Sprint Board](#sprint-board) - - [Pipelines](#pipelines) - - [Creating Issues](#creating-issues) - - [Managing issues/stories](#managing-issuesstories) - - [Spillovers](#spillovers) - - [Epics](#epics) - - [Recurring Team Meetings](#recurring-team-meetings) - - [On-Call](#on-call) ## Overview @@ -83,91 +72,3 @@ The release process will be improved and invested in, running a retrospective an Feedback comes from the retro issue created during the release and component level retrospectives. A meeting could be run to capture additional feedback if desired. This process is focused on recording what happened to make remedies. After the retro items are in, a final summary is written as a comment on the retrospective issue. The comment includes areas of consideration for the project alongside action items with owners to drive them, [example](https://github.com/opensearch-project/opensearch-build/issues/880) summary. - -## ZenHub Process Workflow - -We follow agile methodologies for our development and release process. We use GitHub issues with annotations via ZenHub to manage and track our stories and issues to effectively manage them over the sprint. - -### What is [ZenHub](https://www.zenhub.com/)? - -ZenHub is an agile project management and product roadmaps solution, natively integrated into GitHub. It is free to use for opensource repository and comes with a paid membership to manage private repositories. -We currently use ZenHub only with our public and opensource repositories. - -### Setting up ZenHub - -ZenHub can be easily added as an [extension]((https://www.zenhub.com/extension)) to chrome and firefox which can be downloaded for free from the ZenHub website. -Alternatively, we can use a the ZenHub [webapp link](https://app.zenhub.com/workspaces/engineering-effectiveness-614cf4272a385f0015d2b48f/board?repos=357723952,406037663) to view the board. - -### Sprint Board - -Once the ZenHub extension is installed, ZenHub board can be accessed using the ZenHub tab on GitHub. - -![img.png](zenhub_tab_image.png) - -If you are using the webapp - here is the [link](https://app.zenhub.com/workspaces/engineering-effectiveness-614cf4272a385f0015d2b48f/board?repos=357723952,406037663) - -#### Pipelines - -1. **New Issues -** Issues to be reviewed and estimated before being added to the Product Backlog. -2. **Icebox -** Low priority Issues that do not need to be addressed in the near future**.** -3. **Product Backlog -** Upcoming Issues that have been reviewed, estimated, and prioritized top-to-bottom. -4. **Sprint Backlog -** Issues ready to be worked on in the sprint, prioritized top-to-bottom. -5. **In Progress -** Issues currently being worked on by the team. -6. **Review/QA -** Issues open to the team for review and testing. Code complete, pending feedback. -7. **Done -** Issues tested and ready to be deployed to production. Verify the acceptance criteria and close the issue. -8. **Closed -** Issues that are deployed to production and closed - -Description for each pipeline can also be found on the sprint board by clicking on the 3 dots next to the pipleine name. - -### Creating Issues - -Follow the steps below to create issues on ZenHub workflow - - -1. Create the issue for the desired repository following the required guidelines for mandatory and optional fields on GitHub. -2. Add an acceptance criteria for the issue -3. Add relevant tags to the issue. This would help us to track and filter issues. -4. Select the correct pipeline for the issue (defaults to New Issues ) -5. Mark the issue for a sprint (if known) - -### Managing issues/stories - -1. Everyone working on a task should ensure the following - - 1. Have an issue associated with it to record the work - 2. The issue should be assigned - 3. The issue should have an estimate set - 4. The issue should have the correct pipeline -2. Pull requests raised should be assigned and linked to their issues. There should not be a PR without an issue. -3. If you are working on an issue that belongs to a private repository, create an issue in the opensearch-build repository with only public details to track your work. - -#### Spillovers - -Spillover issues that were a part of the sprint but were not completed are a good indicator for improvement areas. - -These issues will automatically be moved to the next sprint. There are 3 possible cases in this scenario : - -1. **Issue is still in sprint backlog -** This is an indication that we need to look again at our sprint planning to help plan better for the sprint. -2. **Issue is in progress -** This means that we need to create smaller issues such that these can be completed in a sprint. -3. **Issue is in Review -** These issues should be closed at a priority in the upcoming sprint. - -### Epics - -An epic is *a large body of work that can be broken down into a number of smaller stories*, or sometimes called “[META] Issues”. Epics often encompass multiple teams, on multiple projects, and can even be tracked on multiple boards. Epics are almost always delivered over a set of sprints. - -ZenHub provides an elegant way to incorporate epics reducing a lot of manual work compared to meta issues and easy viewing. Click [here](https://help.zenhub.com/support/solutions/articles/43000010341-an-intro-to-zenhub-epics) for more details. - -### Recurring Team Meetings - -- **Standup -** Daily standups can easily be managed using the sprint board. The moderator should select the filter for the current sprint and change filter for assignees as we move forward with the standup. -This would ensure that all the tasks the an individual is working on is correctly represented on the sprint board.
- - Everyone should spend approximately 1 minute to discuss the work without interruption, answering questions like - What did I do yesterday? What is the plan for today? What help I might need from others? After everyone turns, we can discuss go-backs if any. The Moderator keeps track of the time. - -- **Grooming -** All team members come together to add items to the Product Backlog. These issues/stories should have been reviewed, estimated, and prioritized top-to-bottom. - -- **Planning -** We go over the product backlog to see what all do we need to complete for the current sprint. - -- **Retrospective -** This meeting is held at the end of a sprint used to discuss what went well during the previous sprint cycle and what can be improved for the next sprint. - -### On-Call - -Since on-call is a weekly rotation, we do not create an issue for on-call. However, if on-call requires you to work on a bug, please make sure that we have issue associated with the task for tracking. diff --git a/ONBOARDING.md b/ONBOARDING.md index ca07d4caec..ca88e7e083 100644 --- a/ONBOARDING.md +++ b/ONBOARDING.md @@ -19,7 +19,7 @@ Add the new plugin to the [opensearch-plugins meta](https://github.com/opensearc ### Onboard to Build Workflow -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](/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. +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. @@ -33,15 +33,15 @@ Add the new plugin to the [opensearch-plugins meta](https://github.com/opensearc ### Onboard to `test-workflow` -1. Update the test configuration file (use 1.3.0 as an example), [opensearch-1.3.0-test.yml](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. +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. -2. For integration testing, the `test-workflow` runs integration tests available in the plugin repository. You will need to add `integ-test` config for your plugin in opensearch-1.3.0-test.yml, [example](manifests/1.3.0/opensearch-dashboards-1.3.0-test.yml). +2. For integration testing, the `test-workflow` runs integration tests available in the plugin repository. You will need to add `integ-test` config for your plugin in opensearch-1.3.0-test.yml, [example](https://github.com/opensearch-project/opensearch-build/blob/opensearch-1.3.0/manifests/1.3.0/opensearch-1.3.0-test.yml). 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. 2. If your plugin is dependent on `job-scheduler` zip, you can define that in `build-dependencies` in the config. Currently, the test workflow only supports `job-scheduler` as build dependency. Please create an issue if your plugin needs more support. -3. For backward compatibility testing, the `test-workflow` runs backward compatibility tests available in the plugin repository, (see [reference]((https://github.com/opensearch-project/anomaly-detection/blob/d9a122d05282f7efc1e24c61d64f18dec0fd47af/build.gradle#L428))). Like integration test, it has a set of configurable options defined in opensearch-1.3.0-test.yml, [example](manifests/1.3.0/opensearch-1.3.0-test.yml). +3. For backward compatibility testing, the `test-workflow` runs backward compatibility tests available in the plugin repository, (see [reference](https://github.com/opensearch-project/anomaly-detection/blob/d9a122d05282f7efc1e24c61d64f18dec0fd47af/build.gradle#L428)). Like integration test, it has a set of configurable options defined in opensearch-1.3.0-test.yml, [example](https://github.com/opensearch-project/opensearch-build/blob/opensearch-1.3.0/manifests/1.3.0/opensearch-1.3.0-test.yml). 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. @@ -57,14 +57,14 @@ See https://github.com/opensearch-project/opensearch-build/issues/1234 for detai 1. Create a Jenkins workflow that utilizes one of the [build libraries](https://github.com/opensearch-project/opensearch-build-libraries#library-details) to publish the artifacts to right platform. Please check the [library requirements and retrieval methods](https://github.com/opensearch-project/opensearch-build-libraries#jenkins-shared-libraries) before using it. 1. For publishing to a new platform (other than ones specified above) a new library needs to be added. (ETA: 2 weeks) 1. **Release Drafter**: Release drafter is a GitHub Action workflow that drafts a release that may or may not contain the release artifacts. The drafted release acts as a trigger to the Jenkins workflow. It also acts as a staging environment for release artifacts. This is to make sure the build environment remains the same even for release artifacts. [Example](https://github.com/opensearch-project/opensearch-py/blob/main/.github/workflows/release-drafter.yml) - * _**2 Person Review**_ It is highly recommended to add 2PR approval for any release workflow. In universal release process this can be added to release-drafter workflow as that is the starting point to trigger any release. See how to [add the mechanism in the workflow](https://github.com/opensearch-project/opensearch-dsl-py/pull/102). The mentioned solution creates an issues that notifies and assignes the reviewers. [Example](https://github.com/gaiksaya/opensearch-dsl-py/issues/6)_ + * _**2 Person Review**_ It is highly recommended to add 2 PR approval for any release workflow. In universal release process this can be added to release-drafter workflow as that is the starting point to trigger any release. See how to [add the mechanism in the workflow](https://github.com/opensearch-project/opensearch-dsl-py/pull/102). The mentioned solution creates an issue that notifies and assigns the reviewers. [Example](https://github.com/gaiksaya/opensearch-dsl-py/issues/6). 1. **Jenkins Workflow:** Once the Jenkins workflow is added to the repository, onboard the workflow to publicly available [CI system](https://build.ci.opensearch.org/) 1. Create a `New Item` 2. Name it `-release` 3. Select `Pipeline` as type of the project 4. Hit `Ok` and scroll to the bottom of the page 5. Select "Pipeline script from SCM" under Pipeline section - - _SCM_: Github repository link. eg: https://github.com/opensearch-project/opensearch-build + - _SCM_: GitHub repository link. eg: https://github.com/opensearch-project/opensearch-build - _Script_ Path: Relative path to jenkins file. eg: jenkins/check-for-build.jenkinsfile 6. Run the workflow once in order to update the configuration of the Jenkins Workflow. You can abort once the workflow starts pulling the docker image. 1. **GitHub Webhook**: Add webhook to your GitHub repository by going to repository settings → Click `Webhooks`: @@ -75,7 +75,7 @@ See https://github.com/opensearch-project/opensearch-build/issues/1234 for detai | SSL verification | Enable | | Which events would you like to trigger this webhook | Releases. Please ensure to deselect the default option "Pushes" | | Active | Enable | -1. Once a webhook is added, it will send a ping to check the connectivity (✅). You can check the ping by going to repistory settings → Webhooks → Click on `Recent Deliveries` tabs +1. Once a webhook is added, it will send a ping to check the connectivity (✅). You can check the ping by going to repository settings → Webhooks → Click on `Recent Deliveries` tabs 1. Add `RELEASING.md` file to the repository documenting how to release the artifact. [Example](https://github.com/opensearch-project/opensearch-py-ml/blob/main/RELEASING.md) 1. **Adding tests:** Each library has a respective library tester associated with it that can be used to test you jenkins workflow. This tests can be used to verify that the workflow is making the calls. The build system used is gradle. 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. diff --git a/README.md b/README.md index ad250ee2b2..eb39d1a86a 100644 --- a/README.md +++ b/README.md @@ -16,7 +16,7 @@ - [Min snapshots](#min-snapshots) - [CI/CD Environment](#cicd-environment) - [Build Numbers](#build-numbers) - - [Latest Distribution Url](#latest-distribution-url) + - [Latest Distribution URL](#latest-distribution-url) - [Testing the Distribution](#testing-the-distribution) - [Checking Release Notes](#checking-release-notes) - [Signing Artifacts](#signing-artifacts) @@ -27,7 +27,7 @@ - [Releasing for Linux](#releasing-for-linux) - [Releasing for FreeBSD](#releasing-for-freebsd) - [Releasing for Windows](#releasing-for-windows) - - [Releasing for MacOS](#releasing-for-macos) + - [Releasing for macOS](#releasing-for-macos) - [Utilities](#utilities) - [Checking Out Source](#checking-out-source) - [Cross-Platform Builds](#cross-platform-builds) @@ -52,9 +52,9 @@ The OpenSearch project releases as versioned distributions of OpenSearch, OpenSe #### Release labels: -* **Alpha** - The code is released with instructions to build. Built distributions of the software may not be available. Some features many not be complete. Additional testing and developement work is planned. Distributions will be postfixed with `-alphaX` where "X" is the number of the alpha version (e.g., "2.0-alpha1"). -* **Beta** - Built distributions of the software are available. All features are completed. Additional testing and developement work is planned. Distributions will be postfixed with `-betaX` where "X" is the number of the beta version (e.g., "2.0.0-beta1"). -* **Release Candidate** - Built distributions of the software are available. All features are completed. Code is tested and minimal validation remains. At this stage the software is potentially stable and will release unless signficant bugs emerge. Distributions will be postfixed with `-rcX` where "X" is the number of the release candidate version (e.g., "2.0.0-rc1"). +* **Alpha** - The code is released with instructions to build. Built distributions of the software may not be available. Some features many not be complete. Additional testing and development work is planned. Distributions will be postfixed with `-alphaX` where "X" is the number of the alpha version (e.g., "2.0-alpha1"). +* **Beta** - Built distributions of the software are available. All features are completed. Additional testing and development work is planned. Distributions will be postfixed with `-betaX` where "X" is the number of the beta version (e.g., "2.0.0-beta1"). +* **Release Candidate** - Built distributions of the software are available. All features are completed. Code is tested and minimal validation remains. At this stage the software is potentially stable and will release unless significant bugs emerge. Distributions will be postfixed with `-rcX` where "X" is the number of the release candidate version (e.g., "2.0.0-rc1"). * **Generally Available** - Built distributions of the software are available. All features are completed and documented. All testing is completed. Distributions for generally available versions are not postfixed with an additional label (e.g., "2.0.0"). @@ -82,15 +82,15 @@ See [build workflow](src/build_workflow) for more information. ./assemble.sh builds/opensearch/manifest.yml ``` -The assembling step takes output from the build step, installs plugins, and assembles a full distribition into the `dist` folder. +The assembling step takes output from the build step, installs plugins, and assembles a full distribution into the `dist` folder. See [assemble workflow](src/assemble_workflow) for more information. #### Building Patches -A patch release contains output from previous versions mixed with new source code. Manifests can mix such references. See [opensearch-1.3.1.yml](/manifests/1.3.1/opensearch-1.3.1.yml) for an example. +A patch release contains output from previous versions mixed with new source code. Manifests can mix such references. See [opensearch-1.3.1.yml](https://github.com/opensearch-project/opensearch-build/blob/opensearch-1.3.1/manifests/1.3.1/opensearch-1.3.1.yml) for an example. -OpenSearch is often released with changes in `opensearch-min`, and no changes to plugins other than a version bump. This can be performed by a solo Engineer following [a cookbook](https://github.com/opensearch-project/opensearch-plugins/blob/main/META.md#increment-a-version-in-every-plugin). See also [opensearch-build#1375](https://github.com/opensearch-project/opensearch-build/issues/1375) which aims to automate incrementing versions for the next development iteration. +OpenSearch is often released with changes in `opensearch-min`, and no changes to plugins other than a version bump. This can be performed by a solo engineer following [a cookbook](https://github.com/opensearch-project/opensearch-plugins/blob/main/META.md#increment-a-version-in-every-plugin). See also [opensearch-build#1375](https://github.com/opensearch-project/opensearch-build/issues/1375) which aims to automate incrementing versions for the next development iteration. #### Min Snapshots @@ -100,7 +100,7 @@ Linux: ``` https://artifacts.opensearch.org/snapshots/core/opensearch/-SNAPSHOT/opensearch-min--SNAPSHOT-linux-x64-latest.tar.gz ``` -Macos: +macOS: ``` https://artifacts.opensearch.org/snapshots/core/opensearch/-SNAPSHOT/opensearch-min--SNAPSHOT-darwin-x64-latest.tar.gz ``` @@ -118,7 +118,7 @@ See [jenkins](./jenkins) and [docker](./docker) for more information. #### Build Numbers -The distribution url and the build output manifest include a Jenkins auto-incremented build number. For example, the [manifest](https://ci.opensearch.org/ci/dbc/distribution-build-opensearch/2.2.0/5905/linux/x64/rpm/dist/opensearch/manifest.yml) from [OpenSearch build 5905](https://build.ci.opensearch.org/job/distribution-build-opensearch/5905/) contains the following. +The distribution URL and the build output manifest include a Jenkins auto-incremented build number. For example, the [manifest](https://ci.opensearch.org/ci/dbc/distribution-build-opensearch/2.2.0/5905/linux/x64/rpm/dist/opensearch/manifest.yml) from [OpenSearch build 5905](https://build.ci.opensearch.org/job/distribution-build-opensearch/5905/) contains the following. ```yml build: @@ -130,22 +130,22 @@ build: id: '5905' ``` -#### Latest Distribution Url +#### Latest Distribution URL Use the `latest` keyword in the URL to obtain the latest build for a given version. For example `https://ci.opensearch.org/ci/dbc/distribution-build-opensearch/2.2.0/latest/linux/x64/rpm/dist/opensearch/manifest.yml` redirects to [build 5905](https://ci.opensearch.org/ci/dbc/distribution-build-opensearch/2.2.0/5905/linux/x64/rpm/dist/opensearch/manifest.yml) at the time of writing this. -The `latest` keyword is resolved to a specific build number by checking an `index.json` [file](https://ci.opensearch.org/ci/dbc/distribution-build-opensearch/2.2.0/index.json). This file has contents such as this. +The `latest` keyword is resolved to a specific build number by checking the `index.json` [file](https://ci.opensearch.org/ci/dbc/distribution-build-opensearch/2.2.0/index.json). This file has contents such as this. ``` {"latest":"5905"} ``` -The file is updated when a distribution build job is completed for the given product and version (or is created when such distribution job succeeds for the first time). Since one distribution build job consists of multiple stages for different combinations of distribution type, platform and architecture, the `index.json` is only modified once all stages succeed. With this said, the `latest` url only works when the distribution build job succeeds at least once for the given product and version. +The file is updated when a distribution build job is completed for the given product and version (or is created when such distribution job succeeds for the first time). Since one distribution build job consists of multiple stages for different combinations of distribution type, platform and architecture, the `index.json` is only modified once all stages succeed. With this said, the `latest` URL only works when the distribution build job succeeds at least once for the given product and version. -The resolution logic is implemented in the [CloudFront url rewriter](https://github.com/opensearch-project/opensearch-ci/tree/main/resources/cf-url-rewriter). -The TTL (time to live) is set to `5 mins` which means that the `latest` url may need up to 5 mins to get new contents after `index.json` is updated. +The resolution logic is implemented in the [CloudFront URL rewriter](https://github.com/opensearch-project/opensearch-ci/tree/main/resources/cf-url-rewriter). +The TTL (time to live) is set to `5 mins` which means that the `latest` URL may need up to 5 mins to get new contents after `index.json` is updated. -All the artifacts accessible through the regular distribution url can be accessed by the `latest` url. This includes both OpenSearch Core, OpenSearch Dashboards Core and their plugins. +All the artifacts accessible through the regular distribution URL can be accessed by the `latest` URL. This includes both OpenSearch Core, OpenSearch Dashboards Core and their plugins. For example, you can download the latest .tar.gz distribution build of OpenSearch 2.2.0 directly at `https://ci.opensearch.org/ci/dbc/distribution-build-opensearch/2.2.0/latest/linux/x64/tar/dist/opensearch/opensearch-2.2.0-linux-x64.tar.gz`, without having to first download and parse the [complete build manifest](https://ci.opensearch.org/ci/dbc/distribution-build-opensearch/2.2.0/latest/linux/x64/tar/dist/opensearch/manifest.yml). @@ -167,7 +167,7 @@ See [src/test_workflow](./src/test_workflow) for more information. #### Checking Release Notes -Workflow to check if the release notes exists or not and shows the latest commit for OpenSearch and Dashboard distributions. +Workflow to check if the release notes exist or not and shows the latest commit for OpenSearch and Dashboard distributions. To run: ```bash @@ -189,12 +189,12 @@ The tool currently supports following platforms for signing. ##### PGP -Anything can be signed using PGP signing eg: tarball, any type of file, etc. A .sig file will be returned containing the signature. OpenSearch and OpenSearch dashboards distributions, components such as data prepper, etc as well as maven artifacts are signed using PGP signing. See [this page](https://opensearch.org/verify-signatures.html) for how to verify signatures. +Anything can be signed using PGP signing eg: tarball, any type of file, etc. A `.sig` file will be returned containing the signature. OpenSearch and OpenSearch dashboards distributions, components such as data prepper, etc. as well as maven artifacts are signed using PGP signing. See [this page](https://opensearch.org/verify-signatures.html) for how to verify signatures. ##### Windows -Windows signing can be used to sign windows executables such as .msi, .msp, .msm, .cab, .dll, .exe, .appx, .appxbundle, .msix, .msixbundle, .sys, .vxd, .ps1, .psm1, and any PE file that is supported by [Signtool.exe](https://docs.microsoft.com/en-us/dotnet/framework/tools/signtool-exe). Various windows artifacts such as SQL OBDC, opensearch-cli, etc are signed using this method. +Windows signing can be used to sign windows executables such as `.msi, .msp, .msm, .cab, .dll, .exe, .appx, .appxbundle, .msix, .msixbundle, .sys, .vxd, .ps1, .psm1`, and any PE file that is supported by [Signtool.exe](https://docs.microsoft.com/en-us/dotnet/framework/tools/signtool-exe). Various windows artifacts such as SQL OBDC, opensearch-cli, etc are signed using this method. Windows code signing uses EV (Extended Validated) code signing certificates. | Types of signing/Details | Digest | Cipher | Key Size| @@ -221,9 +221,9 @@ The Linux / Windows release is managed by a team at Amazon following [this relea The FreeBSD ports and packages for OpenSearch are managed by a community [OpenSearch Team](https://wiki.freebsd.org/OpenSearch) at FreeBSD. When a new release is rolled out, this team will update the port and commit it to the FreeBSD ports tree. Anybody is welcome to help the team by providing patches for [upgrading the ports](https://docs.freebsd.org/en/books/porters-handbook/book/#port-upgrading) following the [FreeBSD Porter's Handbook](https://docs.freebsd.org/en/books/porters-handbook/book/) instructions. -#### Releasing for MacOS +#### Releasing for macOS -At this moment there's no official MacOS distribution. However, this project does support building and assembling OpenSearch for MacOS. See [opensearch-build#37](https://github.com/opensearch-project/opensearch-build/issues/37) and [#38](https://github.com/opensearch-project/opensearch-build/issues/38) for more details. +At this moment there's no official macOS distribution. However, this project does support building and assembling OpenSearch for macOS. See [opensearch-build#37](https://github.com/opensearch-project/opensearch-build/issues/37) and [#38](https://github.com/opensearch-project/opensearch-build/issues/38) for more details. ### Utilities @@ -239,7 +239,7 @@ See [src/checkout_workflow](./src/checkout_workflow) for more information. #### Cross-Platform Builds -You can perform cross-platform builds. For example, build and assemble a Windows distribution on MacOS. +You can perform cross-platform builds. For example, build and assemble a Windows distribution on macOS. ```bash export JAVA_HOME=$(/usr/libexec/java_home) # required by OpenSearch install-plugin during assemble @@ -247,13 +247,13 @@ export JAVA_HOME=$(/usr/libexec/java_home) # required by OpenSearch install-plug ./assemble.sh builds/opensearch/manifest.yml ``` -This will produce `dist/opensearch-1.3.0-SNAPSHOT-windows-x64.zip` on Linux and MacOS. +This will produce `dist/opensearch-1.3.0-SNAPSHOT-windows-x64.zip` on Linux and macOS. #### Sanity Checking the Bundle This workflow runs sanity checks on every component present in the bundle, executed as part of the [manifests workflow](.github/workflows/manifests.yml) in this repository. It ensures that the component GitHub repositories are correct and versions in those components match the OpenSearch version. -The following example sanity-checks components in the the OpenSearch 1.3.0 manifest. +The following example sanity-checks components in the OpenSearch 1.3.0 manifest. ```bash ./ci.sh manifests/1.3.0/opensearch-1.3.0.yml --snapshot diff --git a/RELEASE_PROCESS_OPENSEARCH.md b/RELEASE_PROCESS_OPENSEARCH.md index 977b38ab87..9abf7bd5d0 100644 --- a/RELEASE_PROCESS_OPENSEARCH.md +++ b/RELEASE_PROCESS_OPENSEARCH.md @@ -1,4 +1,4 @@ -- [OpenSearch Releas Process](#opensearch-release-process) +- [OpenSearch Release Process](#opensearch-release-process) - **[Preparation](#preparation)** - [Release Terminology and Knowledge Center](#release-terminology-and-knowledge-center) - [Definitions](#definitions) @@ -103,7 +103,7 @@ These manifests are integral to the comprehensive testing of the core and compon | OpenSearch | OpenSearch Dashboards | | --- | --- | -| [opensearch-2.8.0-test.yml](https://github.com/opensearch-project/opensearch-build/blob/main/manifests/2.8.0/opensearch-2.8.0-test.yml) | [opensearch-dashboards-2.8.0-test.yml](https://github.com/opensearch-project/opensearch-build/blob/main/manifests/2.8.0/opensearch-dashboards-2.8.0-test.yml) +| [opensearch-2.8.0-test.yml](https://github.com/opensearch-project/opensearch-build/blob/opensearch-2.8.0/manifests/2.8.0/opensearch-2.8.0-test.yml) | [opensearch-dashboards-2.8.0-test.yml](https://github.com/opensearch-project/opensearch-build/blob/opensearch-2.8.0/manifests/2.8.0/opensearch-dashboards-2.8.0-test.yml) ##### Build Manifest @@ -129,14 +129,14 @@ The final output of the assemble workflow and manifest that is added to the fina #### AUTOCUT issues -These are the issues created by automation with the distribution build and integ-test workflows failure, the automation detects the component failure and raises an issue in the respective component repo. Sample [integ-test failure AUTOCUT issue](https://github.com/opensearch-project/k-NN/issues/914) and [distribution build failure AUTOCUT issue](https://github.com/opensearch-project/k-NN/issues/732). The created `AUTOCUT` issues will have the updated information with latest build failure details, the automation also detects if the component build has passed and closes the issues automatically. For more details refer the [closeBuildSuccessGithubIssue.groovy](https://github.com/opensearch-project/opensearch-build-libraries/blob/main/vars/closeBuildSuccessGithubIssue.groovy) and [createGithubIssue.groovy](https://github.com/opensearch-project/opensearch-build-libraries/blob/main/vars/createGithubIssue.groovy) libraries part of the distribution build and integ-test worklows. +These are the issues created by automation with the distribution build and integ-test workflows failure, the automation detects the component failure and raises an issue in the respective component repo. Sample [integ-test failure AUTOCUT issue](https://github.com/opensearch-project/k-NN/issues/914) and [distribution build failure AUTOCUT issue](https://github.com/opensearch-project/k-NN/issues/732). The created `AUTOCUT` issues will have the updated information with latest build failure details, the automation also detects if the component build has passed and closes the issues automatically. For more details refer the [closeBuildSuccessGithubIssue.groovy](https://github.com/opensearch-project/opensearch-build-libraries/blob/main/vars/closeBuildSuccessGithubIssue.groovy) and [createGithubIssue.groovy](https://github.com/opensearch-project/opensearch-build-libraries/blob/main/vars/createGithubIssue.groovy) libraries part of the distribution build and integ-test workflows. #### Build Workflows -| Wokflow | Description | +| Workflow | Description | | ----------------------------------------------------------------------------------------------------------------------------- | ------------------- | -| [Check for Build](https://build.ci.opensearch.org/job/check-for-build/) | Workflow that peridically triggers the distribution workflows using parameterized cron. | +| [Check for Build](https://build.ci.opensearch.org/job/check-for-build/) | Workflow that periodically triggers the distribution workflows using parameterized cron. | | [OpenSearch Distribution Build](https://build.ci.opensearch.org/job/distribution-build-opensearch/) | Workflow that is responsible to build/assemble the OpenSearch and its components. | | [OpenSearch Dashboards Distribution Build](https://build.ci.opensearch.org/job/distribution-build-opensearch-dashboards/) | Workflow that is responsible to build/assemble the OpenSearch Dashboards and its components. | | [OpenSearch Integ Test](https://build.ci.opensearch.org/job/integ-test/) | Workflow that runs integ tests for OpenSearch and its components. | @@ -147,24 +147,24 @@ These are the issues created by automation with the distribution build and integ | [Docker Build](https://build.ci.opensearch.org/job/docker-build/) | Workflow that builds the OpenSearch and OpenSearch Dashboards docker images | | [Docker Copy](https://build.ci.opensearch.org/job/docker-copy/) | Workflow that copies the created docker images to multiple DockerHub and ECR repositories | | [Docker Scan](https://build.ci.opensearch.org/job/docker-scan/) | Workflow that checks vulnerabilities for a given docker image as an input. | -| [1.x Maven Publish](https://build.ci.opensearch.org/job/snapshot-maven-publish-1.x/) | Workflow that published snapshot maven artifcats, used only for 1.3.x versions. Fore more details check https://github.com/opensearch-project/job-scheduler/issues/319. | +| [1.x Maven Publish](https://build.ci.opensearch.org/job/snapshot-maven-publish-1.x/) | Workflow that published snapshot maven artifacts, used only for 1.3.x versions. For more details check this [issue-319](https://github.com/opensearch-project/job-scheduler/issues/319). | #### Release Workflows -| Wokflow | Description | +| Workflow | Description | | ---------------------------------------------------------------------------------------- | ------------------- | | [Release Notes Tracker](https://build.ci.opensearch.org/job/release-notes-tracker/) | Workflow that identifies if a component has a release notes added based on the commit history. | | [Promote Repos](https://build.ci.opensearch.org/job/distribution-promote-repos/) | Workflow that signs and promotes the APT/YUM repos to the production buckets accessed via the cloudfront. | -| [Promote artifacts](https://build.ci.opensearch.org/job/distribution-promote-artifacts/) | Workflow that signs and promotes all the release artifcats to the production buckets accessed via the cloudfront. | +| [Promote artifacts](https://build.ci.opensearch.org/job/distribution-promote-artifacts/) | Workflow that signs and promotes all the release artifacts to the production buckets accessed via the cloudfront. | | [Publish to Maven](https://build.ci.opensearch.org/job/publish-to-maven/) | Workflow that signs and publishes to the central maven repository. | -| [Docker Promotion](https://build.ci.opensearch.org/job/docker-promotion/) | Workflow that promotoes the docker images to production docker repositories. | +| [Docker Promotion](https://build.ci.opensearch.org/job/docker-promotion/) | Workflow that promotes the docker images to production docker repositories. | | [Validation Workflow](https://build.ci.opensearch.org/job/distribution-validation) | Workflow that validates the released distribution. | #### Creating a New Version -Each new OpenSearch release process starts when any one component increments a version, typically on the `main` branch. For example, [OpenSearch#1192](https://github.com/opensearch-project/OpenSearch/pull/1192) incremented the version to 2.0. The [version check automation workflow](.github/workflows/versions.yml) will notice this change or it can be triggered [manually](https://github.com/opensearch-project/opensearch-build/actions/workflows/versions.yml), and make a pull request (e.g. [opensearch-build#514](https://github.com/opensearch-project/opensearch-build/pull/514)) that adds a new manifest (e.g. [opensearch-2.0.0.yml](manifests/2.0.0/opensearch-2.0.0.yml). After that's merged, a GitHub issue is automatically opened by [this workflow](.github/workflows/releases.yml) to make a new release using [this release template](.github/ISSUE_TEMPLATE/release_template.md) (e.g. [opensearch-build#566](https://github.com/opensearch-project/opensearch-build/issues/566)). Existing and new components [(re)onboard into every release](ONBOARDING.md) by submitting pull requests to each version's manifest. +Each new OpenSearch release process starts when any one component increments a version, typically on the `main` branch. For example, [OpenSearch#1192](https://github.com/opensearch-project/OpenSearch/pull/1192) incremented the version to 2.0. The [version check automation workflow](.github/workflows/versions.yml) will notice this change or it can be triggered [manually](https://github.com/opensearch-project/opensearch-build/actions/workflows/versions.yml), and make a pull request (e.g. [opensearch-build#514](https://github.com/opensearch-project/opensearch-build/pull/514)) that adds a new manifest (e.g. [opensearch-2.9.0.yml](manifests/2.9.0/opensearch-2.9.0.yml)). After that's merged, a GitHub issue is automatically opened by [this workflow](.github/workflows/releases.yml) to make a new release using [this release template](.github/ISSUE_TEMPLATE/release_template.md) (e.g. [opensearch-build#566](https://github.com/opensearch-project/opensearch-build/issues/566)). Existing and new components [(re)onboard into every release](ONBOARDING.md) by submitting pull requests to each version's manifest. ### Release Manager @@ -183,11 +183,11 @@ This issue captures the state of the OpenSearch release, its assignee is respons #### Release Issue Update -The release issue is created by an [automation workflow](https://github.com/opensearch-project/opensearch-build/blob/main/.github/workflows/releases.yml). Once the release manager is finalized, the release manager should be updating the created release issue. Sample [Release Issue 2.8.0](https://github.com/opensearch-project/opensearch-build/issues/3434). Update the release issue issue so all `__REPLACE_RELEASE-__` placeholders have actual dates. +The release issue is created by an [automation workflow](https://github.com/opensearch-project/opensearch-build/blob/main/.github/workflows/releases.yml). Once the release manager is finalized, the release manager should be updating the created release issue. Sample [Release Issue 2.8.0](https://github.com/opensearch-project/opensearch-build/issues/3434). Update the release issue so all `__REPLACE_RELEASE-__` placeholders have actual dates. ### Increase the Build Frequency -Increase the build frequency for the this release from once a day (H 1 * * *) to once every hour (H/60 * * * *) in [check-for-build.jenkinsfile](https://github.com/opensearch-project/opensearch-build/blob/main/jenkins/check-for-build.jenkinsfile). This will ensure the [Distribution Build](#distribution-build) workflow is called every hour to build and detect the components failure early that are part of the [Input Manifest](#input-manifest). +Increase the build frequency for the release from once a day (H 1 * * *) to once every hour (H/60 * * * *) in [check-for-build.jenkinsfile](https://github.com/opensearch-project/opensearch-build/blob/main/jenkins/check-for-build.jenkinsfile). This will ensure the [Distribution Build](#distribution-build) workflow is called every hour to build and detect the components failure early that are part of the [Input Manifest](#input-manifest). ### Update the Maven Publish Workflow @@ -199,11 +199,11 @@ This section is not required for a patch release. ### Component Release Issues -The component release issues are auto created by the workflows part of the build repo [OpenSearch components](https://github.com/opensearch-project/opensearch-build/blob/main/.github/workflows/os-release-issues.yml), [OpenSearch Dashboards components](https://github.com/opensearch-project/opensearch-build/blob/main/.github/workflows/osd-release-issues.yml). These workflows creates the release issues based on the template [component_release_template.md](https://github.com/opensearch-project/opensearch-build/blob/main/.github/ISSUE_TEMPLATE/component_release_template.md) and links back the global release issue part of the build. Sample component release issues created for [2.10.0](https://github.com/issues?q=is%3Aopen+is%3Aissue+user%3Aopensearch-project+%5BRELEASE%5D+Release+version+2.10.0+in%3Atitle+) +The component release issues are auto created by the workflows part of the build repo [OpenSearch components](https://github.com/opensearch-project/opensearch-build/blob/main/.github/workflows/os-release-issues.yml), [OpenSearch Dashboards components](https://github.com/opensearch-project/opensearch-build/blob/main/.github/workflows/osd-release-issues.yml). These workflows create the release issues based on the template [component_release_template.md](https://github.com/opensearch-project/opensearch-build/blob/main/.github/ISSUE_TEMPLATE/component_release_template.md) and links back the global release issue part of the build. Sample component release issues created for [2.10.0](https://github.com/issues?q=is%3Aopen+is%3Aissue+user%3Aopensearch-project+%5BRELEASE%5D+Release+version+2.10.0+in%3Atitle+). #### Issue Creation Process Overview -Inside the template [component_release_template.md](https://github.com/opensearch-project/opensearch-build/blob/main/.github/ISSUE_TEMPLATE/component_release_template.md), replace the fields `RELEASE_VERSION`, `RELEASE_BRANCH_X`, `RELEASE_BRANCH` and `RELEASE_ISSUE` to desired release values before creating the release issues across the component/plugin repos. Once the fields are replaced use the `meta` and `gh` cli to create the issues. Find the list of components/plugins from the [opensearch-plugins](https://github.com/opensearch-project/opensearch-plugins) repo (for [OpenSearch](https://github.com/opensearch-project/opensearch-plugins/tree/main/plugins), for [OpenSearch Dashboards](https://github.com/opensearch-project/opensearch-plugins/tree/main/dashboards-plugins)) and use the `meta` cli to create the release issues. For more details check the [create-an-issue-in-all-plugin-repos](https://github.com/opensearch-project/opensearch-plugins/blob/main/META.md#create-an-issue-in-all-plugin-repos) section. +Inside the template [component_release_template.md](https://github.com/opensearch-project/opensearch-build/blob/main/.github/ISSUE_TEMPLATE/component_release_template.md), replace the fields `RELEASE_VERSION`, `RELEASE_BRANCH_X`, `RELEASE_BRANCH` and `RELEASE_ISSUE` to desired release values before creating the release issues across the component/plugin repos. Once the fields are replaced, use the `meta` and `gh` cli to create the issues. Find the list of components/plugins from the [opensearch-plugins](https://github.com/opensearch-project/opensearch-plugins) repo (for [OpenSearch](https://github.com/opensearch-project/opensearch-plugins/tree/main/plugins), for [OpenSearch Dashboards](https://github.com/opensearch-project/opensearch-plugins/tree/main/dashboards-plugins)) and use the `meta` cli to create the release issues. For more details check the [create-an-issue-in-all-plugin-repos](https://github.com/opensearch-project/opensearch-plugins/blob/main/META.md#create-an-issue-in-all-plugin-repos) section. ``` meta exec "gh issue create --label v2.8.0 --title 'Release version 2.8.0' --body-file /tmp/opensearch-build/.github/ISSUE_TEMPLATE/component_release_template.md" @@ -211,7 +211,7 @@ meta exec "gh issue create --label v2.8.0 --title 'Release version 2.8.0' --body ### Release Campaigns -If exists any release specific issues/campaigns link it back to the release issue. Sample linked [issues/campaigns](https://github.com/opensearch-project/opensearch-build/issues/3434#issuecomment-1552138916) +If exists any release specific issues/campaigns, link it back to the release issue. Sample linked [issues/campaigns](https://github.com/opensearch-project/opensearch-build/issues/3434#issuecomment-1552138916) ## Release Branch Readiness @@ -305,7 +305,7 @@ All components (which are ready after completion of version increment) ### Release Candidate -Now once all the version increment PR’s are completed and all the components are part of the input manifest, now its time to generate the RC. Use the [Distribution Build](#distribution-build) to generate the release candidate. Use the following section as the reference to generate the RC, validate it and broadcast it for a given release. The process of `Release Candidate Generation and Testing` should commence at least 6 days prior to the release date. +Now once all the version increment PRs are completed and all the components are part of the input manifest, now it's time to generate the RC. Use the [Distribution Build](#distribution-build) to generate the release candidate. Use the following section as the reference to generate the RC, validate it and broadcast it for a given release. The process of `Release Candidate Generation and Testing` should commence at least 6 days prior to the release date. #### Sample Build details @@ -336,7 +336,7 @@ Following are the RPM integ test jobs for a given RC based on the above section #### Docker Build and Scan -Following are the details for the docker image build and scan. The docker images are built using the TAR artifact generated as part of the [Distribution Build](#distribution-build) (From the above example `OS: 7848`, `OSD: 6126`). The [Distribution Build](#distribution-build) workflow with input `BUILD_DOCKER` (Ref [Workflow Trigger](#workflow-trigger)) triggers the [docker-build] workflow as dowmstream. +Following are the details for the docker image build and scan. The docker images are built using the TAR artifact generated as part of the [Distribution Build](#distribution-build) (From the above example `OS: 7848`, `OSD: 6126`). The [Distribution Build](#distribution-build) workflow with input `BUILD_DOCKER` (Ref [Workflow Trigger](#workflow-trigger)) triggers the [docker-build] workflow as downstream. | Docker | build | scan | |----------|----------|----------| @@ -346,7 +346,7 @@ Following are the details for the docker image build and scan. The docker images ##### Docker RC Freeze -This to ensure that [check-for-build.jenkinsfile](https://github.com/opensearch-project/opensearch-build/blob/main/jenkins/check-for-build.jenkinsfile) wont re-build periodically and override the docker, the RC docker is created with build number. This step can be skipped if the input `BUILD_DOCKER: build_docker_with_build_number_tag` (Ref [Workflow Trigger](#workflow-trigger) used in the [Distribution Build](#distribution-build). +This to ensure that [check-for-build.jenkinsfile](https://github.com/opensearch-project/opensearch-build/blob/main/jenkins/check-for-build.jenkinsfile) won't re-build periodically and override the docker, the RC docker is created with build number. This step can be skipped if the input `BUILD_DOCKER: build_docker_with_build_number_tag` (Ref [Workflow Trigger](#workflow-trigger) used in the [Distribution Build](#distribution-build)). | Docker Freeze | copy | |----------|----------| @@ -361,7 +361,7 @@ For running the benchmark tests, use the `benchmark-test` job part of the [Build #### Backwards Compatibility Tests For more details in running the BWC tests refer [Backwards Compatibility Tests](https://github.com/opensearch-project/opensearch-plugins/blob/main/TESTING.md#bwc-tests-on-distribution-bundle-level) section. -On board the components/plugins to the test [Test Manifest](#test-manifest) with the `bwc-test` setting. Example as follows. +On board the components/plugins to the test [Test Manifest](#test-manifest) with the `bwc-test` setting. Example as follows: ``` - name: index-management bwc-test: @@ -375,9 +375,9 @@ Currently, the windows integration tests for a release is manual. The manually t #### Broadcast and Communication -Broadcast the release candidate in OpenSearch public slack workspace and the release GitHub issue using format [sample broadcast mesaage](https://github.com/opensearch-project/opensearch-build/issues/3434#issuecomment-1571201919) to gather votes. +Broadcast the release candidate in OpenSearch public slack workspace and the release GitHub issue using format [sample broadcast message](https://github.com/opensearch-project/opensearch-build/issues/3434#issuecomment-1571201919) to gather votes. -As a release manager it is essential to ensure the successful completion of all the above mentioned jobs. In the event of failures during integration tests or scans, the release manager should collaborate with the component teams and initiate a re-run to ensure that all jobs are executed successfully. +As a release manager, it is essential to ensure the successful completion of all the above mentioned jobs. In the event of failures during integration tests or scans, the release manager should collaborate with the component teams and initiate a re-run to ensure that all jobs are executed successfully. Post all the job related failures in the `Release issue`, Sample [post](https://github.com/opensearch-project/opensearch-build/issues/3331#issuecomment-1550461519). @@ -387,7 +387,7 @@ All the failed logs are in s3 accessed through the cloudfront. Sample [link](htt #### Release Candidate Lock -Stop builds for this version of OpenSearch and/or OpenSearch Dashboards in order to avoid accidental commits going in unknowingly. Restart only if necessary else manually run the build workflow and declare new release candidate. +Stop builds for this version of OpenSearch and/or OpenSearch Dashboards in order to avoid accidental commits going in unknowingly. Restart only if necessary, else manually run the build workflow and declare new release candidate. Once the RC is finalized, in order to exclude the release from running periodically, at this point it is necessary for the release manager to lock the input manifest and update the `check-for-build.jenkins` to remove it from the scheduled execution, sample [PR](https://github.com/opensearch-project/opensearch-build/pull/3523/files). @@ -400,7 +400,7 @@ Ensure that all pre-release activities listed below are completed before proceed #### Release Labeled Issues -Verify all issues labeled with with this release have been resolved. Coordinate with the core/components team to close the gaps in resolving the issues labeled with with this release. +Verify all issues labeled with this release have been resolved. Coordinate with the core/components team to close the gaps in resolving the issues labeled with this release. #### Go or No-Go @@ -420,7 +420,7 @@ Get the Go / No-Go votes from project management committee (PMC) before staging | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Windows | [os-windows-zip-x64](https://build.ci.opensearch.org/job/distribution-promote-artifacts/233/) | [osd-windows-zip-x64](https://build.ci.opensearch.org/job/distribution-promote-artifacts/234/) | | Debian | [os-deb-arm64](https://build.ci.opensearch.org/job/distribution-promote-artifacts/235/), [os-deb-x64](https://build.ci.opensearch.org/job/distribution-promote-artifacts/236/) | [osd-deb-arm64](https://build.ci.opensearch.org/job/distribution-promote-artifacts/237/), [osd-deb-x64](https://build.ci.opensearch.org/job/distribution-promote-artifacts/238/) | -| TAR | [os-tar-arm64](https://build.ci.opensearch.org/job/distribution-promote-artifacts/243/), [os-tar-x64](https://build.ci.opensearch.org/job/distribution-promote-artifacts/246/) | [osd-tar-x64](https://build.ci.opensearch.org/job/distribution-promote-artifacts/244/), [osd-tar-arm64](https://build.ci.opensearch.org/job/distribution-promote-artifacts/245/) | +| TAR | [os-tar-arm64](https://build.ci.opensearch.org/job/distribution-promote-artifacts/243/), [os-tar-x64](https://build.ci.opensearch.org/job/distribution-promote-artifacts/246/) | [osd-tar-arm64](https://build.ci.opensearch.org/job/distribution-promote-artifacts/245/), [osd-tar-x64](https://build.ci.opensearch.org/job/distribution-promote-artifacts/244/) | | RPM | [os-rpm-arm64](https://build.ci.opensearch.org/job/distribution-promote-artifacts/239/), [os-rpm-x64](https://build.ci.opensearch.org/job/distribution-promote-artifacts/240/) | [osd-rpm-arm64](https://build.ci.opensearch.org/job/distribution-promote-artifacts/241/), [osd-rpm-x64](https://build.ci.opensearch.org/job/distribution-promote-artifacts/242/) | @@ -434,7 +434,7 @@ Coordinate with the plugin teams and create a consolidates release notes. Sample Release the artifacts to production distribution channels, update the website and inform the community of the release. #### Maven Promotion -Promote OpenSearch to maven, trigger the `publish-to-maven worfklow` (Ref [Release Workflows](#release-workflows)), sample [run](https://build.ci.opensearch.org/job/publish-to-maven/17/console). +Promote OpenSearch to maven, trigger the `publish-to-maven workflow` (Ref [Release Workflows](#release-workflows)), sample [run](https://build.ci.opensearch.org/job/publish-to-maven/17/console). #### Docker Promotion Publish the images to docker and ECR, trigger the `docker promotion workflow` (Ref [Release Workflows](#release-workflows)), sample [run](https://build.ci.opensearch.org/job/docker-promotion/32/console). @@ -453,11 +453,11 @@ Coordinate with the documentation website team to ensure the changes are in plac ##### Advertise on Social Media -Coordinate with the project management team to ensure the social media advertisement is completed +Coordinate with the project management team to ensure the social media advertisement is completed. #### Release Validation -Use the validation workflow (Ref [Release Workflows](#release-workflows)) to validate the published artifcats, sample [validation workflow run](https://build.ci.opensearch.org/job/distribution-validation/3/console). +Use the validation workflow (Ref [Release Workflows](#release-workflows)) to validate the published artifacts, sample [validation workflow run](https://build.ci.opensearch.org/job/distribution-validation/3/console). ### Release Checklist @@ -497,7 +497,7 @@ The release manager for the current release should ensure that a release manager ## Communication Templates -Please utilize the provided communication templates to effectively coordinate with the teams involved in the release process. These templates are designed to assist you in communicating through the GitHub release issue and the public Slack channel called `#release`. +Please utilize the provided communication templates to effectively coordinate with the teams involved in the release process. These templates are designed to assist you in communicating through the GitHub release issue and the [public Slack #releases channel](https://opensearch.slack.com/archives/C0561HRK961). ### Release Announcement diff --git a/docker/release/README.md b/docker/release/README.md index 3f38dedbd0..a3837b2bc8 100644 --- a/docker/release/README.md +++ b/docker/release/README.md @@ -62,7 +62,7 @@ The OpenSearch and OpenSearch-Dashboards Docker image is based on [AmazonLinux c ``` ./build-image-single-arch.sh -v 1.0.0 -f ./dockerfiles/opensearch-dashboards.al2.dockerfile -p opensearch-dashboards -a arm64 -t opensearch-dashboards-1.0.0.tar.gz ``` -#### Build multi-arch image with this commands (only support x64 + arm64 in one image for now), the image will immediately uploaded to a docker registry so you need to provide docker repo name: +#### Build multi-arch image with this commands (only support x64 + arm64 in one image for now), the image will be immediately uploaded to a docker registry, so you need to provide docker repo name: * OpenSearch 1.0.0: ``` ./build-image-multi-arch.sh -v 1.0.0 -f ./dockerfiles/opensearch.al2.dockerfile -p opensearch -a "x64,arm64" -r "/:" @@ -116,7 +116,7 @@ Here are three example scenarios of using above variables: $ docker run -it --network="host" -e opensearchproject/opensearch-dashboards:1.1.0 ``` -### Disable Performance Analyzer Agent Cli and Related Configurations +### Disable Performance Analyzer Agent CLI and Related Configurations (This change is added after OpenSearch 2.4.0 and after OpenSearch 1.3.6) * 1 for OpenSearch: diff --git a/scripts/README.md b/scripts/README.md index 45f115911f..3e17fbe925 100644 --- a/scripts/README.md +++ b/scripts/README.md @@ -5,7 +5,7 @@ ## Scripts -This folder contains default and custom scripts located by [src/paths/script_finder.py](../src/paths/script_finder.py)), and the following scripts which are used in either tar/docker or legacy github actions. +This folder contains default and custom scripts located by [src/paths/script_finder.py](../src/paths/script_finder.py), and the following scripts which are used in either tar/docker or legacy github actions. #### Run Deployment Script @@ -20,7 +20,7 @@ This is a script to deploy a single node OpenSearch + OpenSearch-Dashboards clus ulimit -n 65535 ``` - * You must make this edit on the LINUX host and restart docker deamon for OpenSearch process to run. + * You must make this edit on the LINUX host and restart docker daemon for OpenSearch process to run. This will also prevent errors during Dashboards integtest (cypress) so that headless chrome will not crash. * Option 1 (Recommended): ``` @@ -67,7 +67,7 @@ This is a script to deploy a single node OpenSearch + OpenSearch-Dashboards clus ``` ./deploy_single_tar_cluster.sh -v 1.0.0 -t releases -a arm64 -s false ``` - * The script allows in process wait and cleanup, meaning a `SIGINT / SIGTERM / SIGEXIT` or any child process throlwing `EXIT` signal will result in termination of the + * The script allows in process wait and cleanup, meaning a `SIGINT / SIGTERM / SIGEXIT` or any child process throwing `EXIT` signal will result in termination of the cluster as well as the temporary working directory. * If you want to run the deployment in detach mode, just run the command with `nohup &`. diff --git a/zenhub_tab_image.png b/zenhub_tab_image.png deleted file mode 100644 index 1f31ef7a5f..0000000000 Binary files a/zenhub_tab_image.png and /dev/null differ