mozilla
/
experimenter
зеркало из https://github.com/mozilla/experimenter.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
experimenter/.env.integration-tests

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

59 строки
1.7 KiB
Plaintext
Исходник Постоянная ссылка Обычный вид История

Initial commit adding e2e live test. (#5389) * Initial commit adding e2e remote settings live test. * Review updates * Remove recursive flag. * Fix typo.
2021-06-10 20:34:57 +03:00
BUGZILLA_API_KEY=
BUGZILLA_CC_LIST=
BUGZILLA_HOST=https://bugzilla.allizom.org/
fix #5983 bug(nimbus): modify timing on timeout integration test (#5985) Because * With the settings we shipped, timeout=60s, refresh=30s, wait=45*2=90s, we expect that after two invocations of the celery task the experiment will be marked as timed out and 90s gives us that extra 30s to wait, but I've observed that since the timeout calculation is detached from the celery schedule, it may occur that on the second invocation it can be milliseconds below the timeout point and so it won't timeout until the third invocation, and since that's 90s which butts up right against the 90s the test waits it can randomly happen just after the test ends, I verified that the test did in fact end just before the experiment was marked as timed out This commit * Changes the integration test timing to timeout=40s, refresh=20s, wait=60*2=120s which should give enough time for three invocations of the task to occur
2021-07-19 21:22:20 +03:00
CELERY_SCHEDULE_INTERVAL=20
fix #5986 chore(project): increase COMPOSE_HTTP_TIMEOUT (#5987) Because * We've seen a lot of intermittent failures in circle complaining about COMPOSE_HTTP_TIMEOUT being too low This commit * Let's try increasing it and see if that helps
2021-07-17 00:10:17 +03:00
COMPOSE_HTTP_TIMEOUT=1000
Initial commit adding e2e live test. (#5389) * Initial commit adding e2e remote settings live test. * Review updates * Remove recursive flag. * Fix typo.
2021-06-10 20:34:57 +03:00
DB_HOST=db
DB_NAME=postgres
DB_PASS=postgres
DB_USER=postgres
DEBUG=True
DELIVERY_CONSOLE_HOST=
EMAIL_BACKEND=django.core.mail.backends.console.EmailBackend
EMAIL_HOST_PASSWORD=
EMAIL_HOST_USER=
EMAIL_HOST=
EMAIL_PORT=
EMAIL_RELEASE_DRIVERS=
EMAIL_REVIEW=
EMAIL_SENDER=
EMAIL_SHIP=
EXPERIMENTS_PAGINATE_BY=50
FEATURE_ANALYSIS=False
FEATURE_MESSAGE_TYPE=False
fix #7185 chore(project): update local dev authentication for Jetstream (#7218) * fix #7185 chore(project): update local dev authentication for Jetstream * update env vars for integration; add troubleshooting tip * add gcp project access info
2022-05-04 22:07:26 +03:00
GOOGLE_APPLICATION_CREDENTIALS=/tmp/keys/application_default_credentials.json
GOOGLE_ADC_FILE=~/.config/gcloud/application_default_credentials.json
Initial commit adding e2e live test. (#5389) * Initial commit adding e2e remote settings live test. * Review updates * Remove recursive flag. * Fix typo.
2021-06-10 20:34:57 +03:00
HOSTNAME=localhost
KINTO_HOST=http://kinto:8888/v1
KINTO_PASS=experimenter
KINTO_USER=experimenter
fix #5983 bug(nimbus): modify timing on timeout integration test (#5985) Because * With the settings we shipped, timeout=60s, refresh=30s, wait=45*2=90s, we expect that after two invocations of the celery task the experiment will be marked as timed out and 90s gives us that extra 30s to wait, but I've observed that since the timeout calculation is detached from the celery schedule, it may occur that on the second invocation it can be milliseconds below the timeout point and so it won't timeout until the third invocation, and since that's 90s which butts up right against the 90s the test waits it can randomly happen just after the test ends, I verified that the test did in fact end just before the experiment was marked as timed out This commit * Changes the integration test timing to timeout=40s, refresh=20s, wait=60*2=120s which should give enough time for three invocations of the task to occur
2021-07-19 21:22:20 +03:00
KINTO_REVIEW_TIMEOUT=40
Implement most trivial rules from our quality standards (#9711) Because - We are trying to promote [Quality Standards](https://mozilla.github.io/syseng-pod/quality-standards/) across Mozilla's repositories - Experimenter has a [very good score already](https://mozilla.github.io/syseng-pod/quality-standards/#service-Experimenter) This PR - Implements a few of the harmless ones to improve even the score :) --------- Co-authored-by: Jared Lockhart <119884+jaredlockhart@users.noreply.github.com> Co-authored-by: Yashika Khurana <yashikakhuranayashika@gmail.com>
2023-11-10 04:18:05 +03:00
LOG_LEVEL=INFO
Initial commit adding e2e live test. (#5389) * Initial commit adding e2e remote settings live test. * Review updates * Remove recursive flag. * Fix typo.
2021-06-10 20:34:57 +03:00
LOGGING_USE_JSON=False
NORMANDY_API_HOST=
NORMANDY_DEVTOOLS_HOST=https://normandy-devtools.services.mozilla.com/#/local
OPENIDC_CLIENT_ID=
OPENIDC_CLIENT_SECRET=
OPENIDC_HEADER=HTTP_X_FORWARDED_USER
REDIS_DB=0
REDIS_HOST=redis
REDIS_PORT=6379
SECRET_KEY=SOMETHINGSECURE
SENTRY_DSN=
STATSD_BACKEND=markus.backends.logging.LoggingMetrics
SKIP_REVIEW_ACCESS_CONTROL_FOR_DEV_USER=true
STATSD_HOST=
STATSD_PORT=
STATSD_PREFIX=experimenter
chore(project): switch to STORAGES setting for storage providers (#11193) Because * We need to use different storage providers for local dev, tests, and in prod * We used to configure this by using a custom function that called get_storage_class * However get_storage_class is depcated in Django 5.1 * We need to switch to using the STORAGES setting This commit * Removes the old storage setting code * Adds STORAGES to settings.py * Updates tests as necessary fixes #11192
2024-08-20 00:00:26 +03:00
UPLOADS_FILE_STORAGE=django.core.files.storage.FileSystemStorage
fix #9387 feat(cirrus): Cirrus demo app integration tests (#9658) Because - We have a demo app that can test the integration end to end, it has the frontend and backend. - We could stand up the experimenter, launch the experiment or rollout, and push to RS, Cirrus can sync to RS and then the frontend can send a request to the backend and then backend can reach out to Cirrus and can ask for the feature config - When the backend receives the response, can send the response back to the frontend This commit - Tests end-to-end integration between the experimenter, RS, Cirrus, and Demo app - Test both the experiment and rollout end to end fixes #9387
2023-11-03 22:47:01 +03:00
CIRRUS_REMOTE_SETTING_REFRESH_RATE_IN_SECONDS=1
CIRRUS_REMOTE_SETTING_URL=http://kinto:8888/v1/buckets/main/collections/nimbus-web-experiments/records
test(cirrus): Cirrus preview flag (#11167) Because - We added preview flag support for Cirrus to enable them to QA This commit - Add a new test to test preview flag functionality Fixes #11103 Note: Working on to send it to main collection
2024-08-26 18:56:27 +03:00
CIRRUS_REMOTE_SETTING_PREVIEW_URL=http://kinto:8888/v1/buckets/main-workspace/collections/nimbus-web-preview/records
fix #9387 feat(cirrus): Cirrus demo app integration tests (#9658) Because - We have a demo app that can test the integration end to end, it has the frontend and backend. - We could stand up the experimenter, launch the experiment or rollout, and push to RS, Cirrus can sync to RS and then the frontend can send a request to the backend and then backend can reach out to Cirrus and can ask for the feature config - When the backend receives the response, can send the response back to the frontend This commit - Tests end-to-end integration between the experimenter, RS, Cirrus, and Demo app - Test both the experiment and rollout end to end fixes #9387
2023-11-03 22:47:01 +03:00
CIRRUS_APP_ID=demo-app-beta
CIRRUS_APP_NAME=demo_app
CIRRUS_CHANNEL=release
CIRRUS_FML_PATH=./feature_manifest/sample.yml
CIRRUS_SENTRY_DSN=
feat(cirrus): Configure sentry for different projects (#10045) Because - We are using Sentry for all the Cirrus implementing applications such as Monitor, VPN, and so on...... Currently, it is hard to track where the error is coming from until we see the issue in detail. This commit - Sentry supports the concept of environment, so in the same project you can configure different environment - By default, Sentry uses a `production` environment, so the default value used in initialization is `production` - Add support for using environment so that the `cirrus-stage` project can have `monitor-stage` and `vpn-stage` and similarly `cirrus-prod` can have `monitor-prod` and `vpn-prod` environments. Note: Sentry [environment](https://docs.sentry.io/product/sentry-basics/concepts/environments/) selection also makes it easy to filter the issues, for example ![image](https://github.com/mozilla/experimenter/assets/25848231/34f7dd90-c19a-4c5d-9541-9fb8168167ea) Fixes #9999
2024-01-15 21:55:08 +03:00
CIRRUS_ENV_NAME=test_instance_stage
feat(cirrus): Set glean max event buffer value (#10070) Because - When setting up glean sdk on cirrus side, we set the maxEvents to 500, which means it waits on the client side to gather all 500 events, and once it gets 500 then it sends the batch of events. Implementing applications should be able to adjust the value that works best for them. This commit - Add the option to set no. of events to store in buffer through `.env`, by default it uses `10` now Fixes #9534
2024-01-22 23:42:38 +03:00
CIRRUS_GLEAN_MAX_EVENTS_BUFFER=1