From ad7d65c2fd51d24d0a9aaee482d96cfe9beb7442 Mon Sep 17 00:00:00 2001 From: ci-build Date: Wed, 6 Nov 2024 19:08:22 +0000 Subject: [PATCH] [skip ci] Docs updates --- dev/release-process.html | 20 ++++++++++---- print.html | 59 +++++++++++++++++++++++++--------------- searchindex.js | 2 +- searchindex.json | 2 +- testing/load-tests.html | 39 +++++++++++++++----------- 5 files changed, 76 insertions(+), 46 deletions(-) diff --git a/dev/release-process.html b/dev/release-process.html index e0e0795df..7a9455471 100644 --- a/dev/release-process.html +++ b/dev/release-process.html @@ -166,12 +166,20 @@

Versioning

The commit hash of the deployed code is considered its version identifier. The commit hash can be retrieved locally via git rev-parse HEAD.

Load Testing

-

Load testing can be run locally or as a part of the deployment process. Local execution does not -require any labeling in commit messages. For deployment, you have to add a label to the message of -the commit that you wish to deploy in the form of: [load test: (abort|warn)]. In most cases this -will be the merge commit created by merging a GitHub pull request.

-

abort will prevent deployment should the load testing fail while warn will warn via Slack and -continue deployment. For detailed specifics on load testing and this convention, please see the +

Load testing can be performed either locally or during the deployment process. During deployment, +load tests are run against the staging environment before Merino-py is promoted to production.

+

Load tests in continuous deployment are controlled by adding a specific label to the commit message +being deployed. The format for the label is [load test: (abort|skip|warn)]. Typically, this label +is added to the merge commit created when a GitHub pull request is integrated.

+ +

If no label is included in the commit message, the default behavior is to run the load test and +issue a warning if it fails.

+

For more detailed information about load testing procedures and conventions, please refer to the Load Test README.

Logs from load tests executed in continuous deployment are available in the /data volume of the Locust master kubernetes pod.

diff --git a/print.html b/print.html index 029003623..029400ab4 100644 --- a/print.html +++ b/print.html @@ -900,12 +900,20 @@

Versioning

The commit hash of the deployed code is considered its version identifier. The commit hash can be retrieved locally via git rev-parse HEAD.

Load Testing

-

Load testing can be run locally or as a part of the deployment process. Local execution does not -require any labeling in commit messages. For deployment, you have to add a label to the message of -the commit that you wish to deploy in the form of: [load test: (abort|warn)]. In most cases this -will be the merge commit created by merging a GitHub pull request.

-

abort will prevent deployment should the load testing fail while warn will warn via Slack and -continue deployment. For detailed specifics on load testing and this convention, please see the +

Load testing can be performed either locally or during the deployment process. During deployment, +load tests are run against the staging environment before Merino-py is promoted to production.

+

Load tests in continuous deployment are controlled by adding a specific label to the commit message +being deployed. The format for the label is [load test: (abort|skip|warn)]. Typically, this label +is added to the merge commit created when a GitHub pull request is integrated.

+ +

If no label is included in the commit message, the default behavior is to run the load test and +issue a warning if it fails.

+

For more detailed information about load testing procedures and conventions, please refer to the Load Test README.

Logs from load tests executed in continuous deployment are available in the /data volume of the Locust master kubernetes pod.

@@ -1341,31 +1349,38 @@

Distributed GCP Execution - CI Trigger

The load tests are triggered in CI via Jenkins, which has a command overriding the load test Dockerfile entrypoint.

-

Follow the steps bellow to execute the distributed load tests on GCP with a CI trigger:

+

Follow the steps below to execute the distributed load tests on GCP with a CI trigger:

Run Test Session

1. Execute Load Test

-

To automatically kick off load testing in staging along with your pull request commit, you have to -include a label in your git commit. This must be the merge commit on the main branch, since only -the most recent commit is checked for the label. This label is in the form of: -[load test: (abort|warn)]. Take careful note of correct syntax and spacing within the label. There -are two options for load tests, being abort and warn.

-

The abort label will prevent a prod deployment should the load test fail. -Ex. feat: Add feature ABC [load test: abort].

-

The warn label will output a Slack warning should the load test fail, but still allow for prod -deployment. -Ex. feat: Add feature XYZ [load test: warn].

+

To modify the load testing behavior, you must include a label in your Git commit. This must be the +merge commit on the main branch, since only the most recent commit is checked for the label. The +label format is: [load test: (abort|skip|warn)]. Take careful note of correct syntax and spacing +within the label. There are three options for load tests: abort, skip, and warn:

+ +

If no label is included in the commit message, the load test will be executed with the warn +action.

The commit tag signals load test instructions to Jenkins by modifying the Docker image tag. The Jenkins deployment workflow first deploys to stage and then runs load tests if requested. The Docker image tag passed to Jenkins appears as follows: -^(?P<environment>stage|prod)(?:-(?P<task>\w+)-(?P<onfailure>warn|abort))?-(?P<commit>[a-z0-9]+)$.

+^(?P<environment>stage|prod)(?:-(?P<task>\w+)-(?P<action>abort|skip|warn))?-(?P<commit>[a-z0-9]+)$

2. Analyse Results

See Distributed GCP Execution (Manual Trigger) - Analyse Results

3. Report Results