From ad7d65c2fd51d24d0a9aaee482d96cfe9beb7442 Mon Sep 17 00:00:00 2001
From: ci-build The commit hash of the deployed code is considered its version identifier. The commit hash can be
retrieved locally via 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 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 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 The commit hash of the deployed code is considered its version identifier. The commit hash can be
retrieved locally via 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 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 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 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: 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 The The 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: If no label is included in the commit message, the load test will be executed with the The commit tag signals load test instructions to Jenkins by modifying the Docker image tag. The
Jenkins deployment workflow first deploys to Versioning
git rev-parse HEAD
.Load Testing
-[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 test: (abort|skip|warn)]
. Typically, this label
+is added to the merge commit created when a GitHub pull request is integrated.
+
+abort
: Stops the deployment if the load test fails.skip
: Skips load testing entirely during deployment.warn
: Proceeds with the deployment even if the load test fails, but sends a warning notification
+through Slack./data
volume of the
Locust master kubernetes pod.Versioning
git rev-parse HEAD
.Load Testing
-[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 test: (abort|skip|warn)]
. Typically, this label
+is added to the merge commit created when a GitHub pull request is integrated.
+
+abort
: Stops the deployment if the load test fails.skip
: Skips load testing entirely during deployment.warn
: Proceeds with the deployment even if the load test fails, but sends a warning notification
+through Slack./data
volume of the
Locust master kubernetes pod.Distributed GCP Execution - CI Trigger
Run Test Session
1. Execute Load Test
-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
.abort
label will prevent a prod
deployment should the load test fail.
-Ex. feat: Add feature ABC [load test: abort]
.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]
.[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
:
+
+abort
label will prevent a prod deployment if the load test fails
+Ex. feat: Add feature ABC [load test: abort].
skip
label will bypass load testing entirely during deployment
+Ex. feat: Add feature LMN [load test: skip].
warn
label will output a Slack warning if the load test fails but still allow for the
+production deployment
+Ex. feat: Add feature XYZ [load test: warn].
warn
+action.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]+)$
See Distributed GCP Execution (Manual Trigger) - Analyse Results
/data
directory of the locust-master-0
pod in the locust-master
k8s cluster
-in the GCP project of merino-nonprod
. To access the Locust logs:
+/data
directory of the locust-master-0
pod in the locust-master
k8s cluster in the GCP
+project of merino-nonprod
. To access the Locust logs:
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:
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
:
abort
label will prevent a prod deployment if the load test failsfeat: Add feature ABC [load test: abort].
skip
label will bypass load testing entirely during deploymentfeat: Add feature LMN [load test: skip].
warn
label will output a Slack warning if the load test fails but still allow for the
+production deploymentfeat: Add feature XYZ [load test: 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]+)$
See Distributed GCP Execution (Manual Trigger) - Analyse Results
/data
directory of the locust-master-0
pod in the locust-master
k8s cluster
-in the GCP project of merino-nonprod
. To access the Locust logs:
+/data
directory of the locust-master-0
pod in the locust-master
k8s cluster in the GCP
+project of merino-nonprod
. To access the Locust logs: