diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2022-09-20 02:18:09 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2022-09-20 02:18:09 +0300 |
commit | 6ed4ec3e0b1340f96b7c043ef51d1b33bbe85fde (patch) | |
tree | dc4d20fe6064752c0bd323187252c77e0a89144b /doc/development/testing_guide/end_to_end/feature_flags.md | |
parent | 9868dae7fc0655bd7ce4a6887d4e6d487690eeed (diff) |
Add latest changes from gitlab-org/gitlab@15-4-stable-eev15.4.0-rc42
Diffstat (limited to 'doc/development/testing_guide/end_to_end/feature_flags.md')
-rw-r--r-- | doc/development/testing_guide/end_to_end/feature_flags.md | 14 |
1 files changed, 6 insertions, 8 deletions
diff --git a/doc/development/testing_guide/end_to_end/feature_flags.md b/doc/development/testing_guide/end_to_end/feature_flags.md index 33f73304a26..9a39161f1ad 100644 --- a/doc/development/testing_guide/end_to_end/feature_flags.md +++ b/doc/development/testing_guide/end_to_end/feature_flags.md @@ -195,12 +195,10 @@ End-to-end tests should pass with a feature flag enabled before it is enabled on There are two ways to confirm that end-to-end tests pass: - If a merge request adds or edits a [feature flag definition file](../../feature_flags/index.md#feature-flag-definition-and-validation), - two `package-and-qa` jobs (`package-and-qa-ff-enabled` and `package-and-qa-ff-disabled`) are included automatically in the merge request - pipeline. One job enables the defined feature flag and the other job disables it. The jobs execute the same suite of tests to confirm - that they pass with the feature flag either enabled or disabled. -- In some cases, if `package-and-qa` hasn't been triggered automatically, or if it has run the tests with the default feature flag values - (which might not be desired), you can create a Draft MR that enables the feature flag to ensure that all E2E tests pass with the feature - flag enabled. + two `e2e:package-and-test` jobs (`ee:instance-parallel` and `ee:instance-parallel-ff-inverse`) are included automatically in the merge request pipeline. + One job runs the application with default feature flag state and another sets it to inverse value. The jobs execute the same suite of tests to confirm that they pass with the feature flag either enabled or disabled. +- In some cases, if end-to-end test jobs didn't trigger automatically, or if it has run the tests with the default feature flag values (which might not be desired), + you can create a Draft MR that enables the feature flag to ensure that all E2E tests pass with the feature flag enabled and disabled. ### Troubleshooting end-to-end test failures with feature flag enabled @@ -216,8 +214,8 @@ If enabling the feature flag results in E2E test failures, you can browse the ar ### Test execution during feature development If an end-to-end test enables a feature flag, the end-to-end test suite can be used to test changes in a merge request -by running the `package-and-qa` job in the merge request pipeline. If the feature flag and relevant changes have already been merged, you can confirm that the tests -pass on the default branch. The end-to-end tests run on the default branch every two hours, and the results are posted to a +by running the `e2e:package-and-test` job in the merge request pipeline. If the feature flag and relevant changes have already been merged, you can confirm that the tests +pass on the default branch. The end-to-end tests run on the default branch every two hours, and the results are posted to a [Test Session Report, which is available in the testcase-sessions project](https://gitlab.com/gitlab-org/quality/testcase-sessions/-/issues?label_name%5B%5D=found%3Amain). If the relevant tests do not enable the feature flag themselves, you can check if the tests will need to be updated by opening |