debian-mirror-gitlab/doc/development/testing_guide/end_to_end/feature_flags.md

77 lines
2.7 KiB
Markdown
Raw Normal View History

2021-01-29 00:20:46 +05:30
---
stage: none
group: unassigned
2021-02-22 17:27:13 +05:30
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
2021-01-29 00:20:46 +05:30
---
2019-12-26 22:10:19 +05:30
# Testing with feature flags
2021-01-03 14:25:43 +05:30
To run a specific test with a feature flag enabled you can use the `QA::Runtime::Feature` class to
enable and disable feature flags ([via the API](../../../api/features.md)).
2019-12-26 22:10:19 +05:30
2021-01-03 14:25:43 +05:30
Note that administrator authorization is required to change feature flags. `QA::Runtime::Feature`
2021-02-22 17:27:13 +05:30
automatically authenticates as an administrator as long as you provide an appropriate access
2021-01-03 14:25:43 +05:30
token via `GITLAB_QA_ADMIN_ACCESS_TOKEN` (recommended), or provide `GITLAB_ADMIN_USERNAME`
and `GITLAB_ADMIN_PASSWORD`.
2019-12-26 22:10:19 +05:30
2021-01-03 14:25:43 +05:30
Please be sure to include the tag `:requires_admin` so that the test can be skipped in environments
where admin access is not available.
2021-02-22 17:27:13 +05:30
WARNING:
2021-01-03 14:25:43 +05:30
You are strongly advised to [enable feature flags only for a group, project, user](../../feature_flags/development.md#feature-actors),
or [feature group](../../feature_flags/development.md#feature-groups). This makes it possible to
test a feature in a shared environment without affecting other users.
For example, the code below would enable a feature flag named `:feature_flag_name` for the project
created by the test:
2020-04-22 19:07:51 +05:30
2019-12-26 22:10:19 +05:30
```ruby
2020-07-28 23:09:34 +05:30
RSpec.describe "with feature flag enabled", :requires_admin do
2021-01-03 14:25:43 +05:30
let(:project) { Resource::Project.fabricate_via_api! }
2019-12-26 22:10:19 +05:30
before do
2021-01-03 14:25:43 +05:30
Runtime::Feature.enable(:feature_flag_name, project: project)
2019-12-26 22:10:19 +05:30
end
it "feature flag test" do
2021-01-03 14:25:43 +05:30
# Execute the test with the feature flag enabled.
# It will only affect the project created in this test.
2019-12-26 22:10:19 +05:30
end
after do
2021-01-03 14:25:43 +05:30
Runtime::Feature.disable(:feature_flag_name, project: project)
2019-12-26 22:10:19 +05:30
end
end
```
2021-01-03 14:25:43 +05:30
Note that the `enable` and `disable` methods first set the flag and then check that the updated
value is returned by the API.
Similarly, you can enable a feature for a group, user, or feature group:
```ruby
group = Resource::Group.fabricate_via_api!
Runtime::Feature.enable(:feature_flag_name, group: group)
user = Resource::User.fabricate_via_api!
Runtime::Feature.enable(:feature_flag_name, user: user)
feature_group = "a_feature_group"
Runtime::Feature.enable(:feature_flag_name, feature_group: feature_group)
```
2021-02-22 17:27:13 +05:30
If no scope is provided, the feature flag is set instance-wide:
2021-01-03 14:25:43 +05:30
```ruby
# This will affect all users!
Runtime::Feature.enable(:feature_flag_name)
```
2019-12-26 22:10:19 +05:30
## Running a scenario with a feature flag enabled
2021-01-03 14:25:43 +05:30
It's also possible to run an entire scenario with a feature flag enabled, without having to edit
existing tests or write new ones.
2019-12-26 22:10:19 +05:30
2021-01-03 14:25:43 +05:30
Please see the [QA README](https://gitlab.com/gitlab-org/gitlab/tree/master/qa#running-tests-with-a-feature-flag-enabled)
for details.