gitlab-qa 5.13.7 → 5.17.0

Sign up to get free protection for your applications and to get access to all the features.
checksums.yaml CHANGED
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  SHA256:
3
- metadata.gz: 80567a3f14ce823c574bf448dd57339aa9ac95d39514b2c18ec4f8d9094c5e95
4
- data.tar.gz: 4aa694b95e7bc667a58d63d7ac4c2606dbbd3d9a5819cd49e160dfae60b919cc
3
+ metadata.gz: a9c4251f7eaa756abc42d5cb76b0b318ec3b14004331d32a92e125135055ecef
4
+ data.tar.gz: 04bb9549728a2533cfb34b2e5ade00260511fda1d6e4d052769d9682b73b497b
5
5
  SHA512:
6
- metadata.gz: 1a9f28e68a1717e93f7df4dda6de613185b3175417092517d56338d35af67679eed4a8d074e6ee5b6efd1f9d425b761aec3d9a8803d9d993341a9a28b1abde4c
7
- data.tar.gz: da4ca897e44bd8c398c42f431370b73bb482fdb032b059053b759eb0c97646500057961b8a378a789b39cf5ab093e00a4a8577c36fbb6ef9353ce9116b24f98a
6
+ metadata.gz: dfb8a2afb17ac4d47e0c770c8da39a3290d6ac58d6306f3a930d50b08180660c85995ff248b1f50bdd6f8d9fe26b29f8680016b03ff07f85d5600e1bd5c7be90
7
+ data.tar.gz: a84cd2cef18c8f229826b47236edd8749345de2bfb51be1705109d623b0fefec7b09088f46244df206f85665420fb22dbdc3d8a250e617a8ab45876e95fc99d0
@@ -31,6 +31,8 @@ workflow:
31
31
  - if: '$CI_COMMIT_BRANCH == "master"'
32
32
  # For tags, create a pipeline.
33
33
  - if: '$CI_COMMIT_TAG'
34
+ # For triggers from GitLab MR pipelines (and pipelines from other projects), create a pipeline
35
+ - if: '$CI_PIPELINE_SOURCE == "pipeline"'
34
36
 
35
37
  .default-rules:
36
38
  rules:
@@ -830,6 +832,44 @@ ee:praefect-quarantine:
830
832
  QA_CAN_TEST_PRAEFECT: "true"
831
833
  QA_RSPEC_TAGS: "--tag quarantine --tag ~orchestrated"
832
834
 
835
+ ce:gitaly-cluster:
836
+ extends:
837
+ - .test
838
+ - .high-capacity
839
+ - .ce-qa
840
+ - .rspec-report-opts
841
+ variables:
842
+ QA_SCENARIO: "Test::Integration::GitalyCluster"
843
+
844
+ ce:gitaly-cluster-quarantine:
845
+ extends:
846
+ - .test
847
+ - .high-capacity
848
+ - .ce-qa
849
+ - .quarantine
850
+ - .rspec-report-opts
851
+ variables:
852
+ QA_SCENARIO: "Test::Integration::GitalyCluster"
853
+
854
+ ee:gitaly-cluster:
855
+ extends:
856
+ - .test
857
+ - .high-capacity
858
+ - .ee-qa
859
+ - .rspec-report-opts
860
+ variables:
861
+ QA_SCENARIO: "Test::Integration::GitalyCluster"
862
+
863
+ ee:gitaly-cluster-quarantine:
864
+ extends:
865
+ - .test
866
+ - .high-capacity
867
+ - .ee-qa
868
+ - .quarantine
869
+ - .rspec-report-opts
870
+ variables:
871
+ QA_SCENARIO: "Test::Integration::GitalyCluster"
872
+
833
873
  ce:smtp:
834
874
  extends:
835
875
  - .test
@@ -891,7 +931,8 @@ ee:jira-quarantine:
891
931
  staging:
892
932
  script:
893
933
  - unset EE_LICENSE
894
- - exe/gitlab-qa Test::Instance::Staging
934
+ - 'echo "Running: exe/gitlab-qa Test::Instance::Staging ${RELEASE:=$DEFAULT_RELEASE} -- $QA_TESTS $QA_RSPEC_TAGS"'
935
+ - exe/gitlab-qa Test::Instance::Staging ${RELEASE:=$DEFAULT_RELEASE} -- $QA_TESTS $QA_RSPEC_TAGS
895
936
  extends:
896
937
  - .test
897
938
  - .high-capacity
data/README.md CHANGED
@@ -121,11 +121,58 @@ All the scenarios you can run are described in the
121
121
 
122
122
  Note: The GitLab QA tool requires that [Docker](https://docs.docker.com/install/) is installed.
123
123
 
124
- ### How to add new scenarios
125
-
126
- Scenarios (test cases) and scripts to run them are located in the
127
- [CE](https://gitlab.com/gitlab-org/gitlab-ce/tree/master/qa) and
128
- [EE](https://gitlab.com/gitlab-org/gitlab-ee/tree/master/qa)
124
+ ### Command-line options
125
+
126
+ In addition to the [arguments you can use to specify the scenario and
127
+ tests to run](/docs/what_tests_can_be_run.md), you can use the
128
+ following options to control the tool's behavior.
129
+
130
+ **Note:** These are `gitlab-qa` options so if you specify RSpec
131
+ options as well, including test file paths, be sure to add these
132
+ options before the `--` that indicates that subsequent arguments are
133
+ intended for RSpec.
134
+
135
+ | Option | Description |
136
+ | ------ | ----------- |
137
+ | `--no-teardown` | Skip teardown of containers after the scenario completes |
138
+ | `--no-tests` | Orchestrates the docker containers but does not run the tests. Implies `--no-teardown` |
139
+
140
+ For example, the following command would start an EE GitLab Docker
141
+ container and would leave the instance running, but would not run the
142
+ tests:
143
+
144
+ ```plaintext
145
+ $ gitlab-qa Test::Instance::Image EE --no-tests
146
+ ```
147
+
148
+ GitLab QA will have automatically run the `docker ps` command to show
149
+ the port that container is running on, for example:
150
+
151
+ ```plaintext
152
+ ...
153
+ Skipping tests.
154
+ The orchestrated docker containers have not been removed.
155
+ Docker shell command: `docker ps`
156
+ CONTAINER ID IMAGE ... PORTS
157
+ fdeffd791b69 gitlab/gitlab-ee:nightly 22/tcp, 443/tcp, 0.0.0.0:32768->80/tcp
158
+ ```
159
+
160
+ You could then run tests against that instance in a similar way to
161
+ [running tests against GDK](/docs/run_qa_against_gdk.md). This can be
162
+ useful if you want to run and debug a specific test, for example:
163
+
164
+ ```plaintext
165
+ # From /path/to/gdk/gitlab/qa
166
+ $ bundle exec bin/qa Test::Instance::All http://localhost:32768 -- qa/specs/features/browser_ui/3_create/merge_request/create_merge_request_spec.rb
167
+ ```
168
+
169
+ ### How to add new tests
170
+
171
+ Please see the [Beginner's guide to writing end-to-end tests](https://docs.gitlab.com/ee/development/testing_guide/end_to_end/beginners_guide.html).
172
+
173
+ Test cases and scripts to run them are located in the
174
+ [GitLab FOSS](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/qa) and
175
+ [GitLab](https://gitlab.com/gitlab-org/gitlab/tree/master/qa)
129
176
  repositories under the `qa/` directory, so please also check the documentation
130
177
  there.
131
178
 
@@ -1,5 +1,6 @@
1
- # What tests can be run?
2
1
 
2
+ # What tests can be run?
3
+ [[_TOC_]]
3
4
  ## The two types of QA tests
4
5
 
5
6
  First of all, the first thing to choose is whether you want to run orchestrated
@@ -28,6 +29,8 @@ For more details on the internals, please read the
28
29
 
29
30
  ## Supported GitLab environment variables
30
31
 
32
+ All environment variables used by GitLab QA should be defined in [`lib/gitlab/qa/runtime/env.rb`](https://gitlab.com/gitlab-org/gitlab-qa/-/blob/master/lib/gitlab/qa/runtime/env.rb).
33
+
31
34
  | Variable | Default | Description | Required |
32
35
  |-----------------------|-----------|-----------------------|----------|
33
36
  | `GITLAB_USERNAME` | `root` | Username to use when signing into GitLab. | Yes|
@@ -53,7 +56,8 @@ For more details on the internals, please read the
53
56
  | `GITLAB_SANDBOX_NAME` | `gitlab-qa-sandbox` | The sandbox group name the test suite is going to use. | No|
54
57
  | `GITLAB_QA_ACCESS_TOKEN`|- | A valid personal access token with the `api` scope. This is used for API access during tests, and is used in the version that staging is currently running. An existing token that is valid on [`Test::Instance::Staging`](#testinstancestaging) scenario to retrieve the staging can be found in the shared 1Password vault. |No|
55
58
  | `GITLAB_QA_ADMIN_ACCESS_TOKEN` |- | A valid personal access token with the `api` scope from a user with admin access. Used for API access as an admin during tests. | No|
56
- | `EE_LICESEN` |- | Enterprise Edition license. | No|
59
+ | `GITLAB_QA_CONTAINER_REGISTRY_ACCESS_TOKEN` | - | A valid personal access token with the `read_registry` scope. Used to [access the container registry on `registry.gitlab.com` when tests run in a CI job that _is not_ triggered via another pipeline](https://gitlab.com/gitlab-org/gitlab-qa/-/blob/364addb83e7b136ff0f9d8719ca9553d290aa9ab/lib/gitlab/qa/release.rb#L152). For example, if you manually run a [new Staging pipeline](https://ops.gitlab.net/gitlab-org/quality/staging/-/pipelines/new), this token will be used. | No |
60
+ | `EE_LICENSE` |- | Enterprise Edition license. | No|
57
61
  | `QA_ARTIFACTS_DIR` |`/tmp/gitlab-qa`| Path to a directory where artifacts (logs and screenshots) for failing tests will be saved. | No|
58
62
  | `DOCKER_HOST` |`http://localhost`| Docker host to run tests against. | No|
59
63
  | `CHROME_HEADLESS` |- | When running locally, set to `false` to allow Chrome tests to be visible - watch your tests being run. | No|
@@ -83,8 +87,27 @@ For more details on the internals, please read the
83
87
 
84
88
  ## Running tests with a feature flag enabled
85
89
 
86
- It is possible to enable a feature flag before running tests. See the [QA
87
- framework documentation](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/qa/README.md#running-tests-with-a-feature-flag-enabled) for details.
90
+ It is possible to enable or disable a feature flag before running tests.
91
+ To test a Gitlab image with a feature flag enabled, run this command:
92
+ ```
93
+ $ gitlab-qa Test::Instance::Image gitlab/gitlab-ee:12.4.0-ee.0 --enable-feature feature_flag_name
94
+ ```
95
+
96
+ To run a test with feature flag disabled, run this command:
97
+ ```
98
+ $ gitlab-qa Test::Instance::Image gitlab/gitlab-ee:12.4.0-ee.0 --disable-feature feature_flag_name
99
+ ```
100
+
101
+ You an also test a GitLab image multiple times with different feature flag settings:
102
+ ```
103
+ $ gitlab-qa Test::Instance::Image gitlab/gitlab-ee:12.4.0-ee.0 --disable-feature feature_flag_name --enable-feature feature_flag_name
104
+ ```
105
+ This will first disable `feature_flag_name` flag and run the tests and then enable it and run the tests again.
106
+
107
+ You can pass any number of feature flag settings. The tests will run once for each setting.
108
+
109
+ See the [QA framework documentation](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/qa/README.md#running-tests-with-a-feature-flag-enabled)
110
+ for information on running the tests with different feature flag settings from the QA framework.
88
111
 
89
112
  ## Specifying the GitLab version
90
113
 
@@ -545,7 +568,7 @@ in the GitLab CE project).
545
568
 
546
569
  - `GITLAB_QA_DEV_ACCESS_TOKEN`: A valid personal access token for the
547
570
  `gitlab-qa-bot` on `dev.gitlab.org` with the `registry` scope.
548
- This is used to pull the QA Docker from the Omnibus GitLab `dev` Container Registry.
571
+ This is used to pull the QA Docker image from the Omnibus GitLab `dev` Container Registry.
549
572
  If the variable isn't present, the QA image from Docker Hub will be used.
550
573
  This can be found in the shared 1Password vault.
551
574
 
@@ -560,6 +583,41 @@ $ export GITLAB_PASSWORD="$GITLAB_QA_PASSWORD"
560
583
  $ gitlab-qa Test::Instance::Staging
561
584
  ```
562
585
 
586
+ ### `Test::Instance::StagingGeo`
587
+
588
+ This scenario tests that the Geo staging deployment (with [`staging.gitlab.com`](https://staging.gitlab.com) as the primary site and [`geo.staging.gitlab.com`](https://geo.staging.gitlab.com) as the secondary site) works as expected by running tests tagged `:geo` against it. This is done by spinning up a GitLab QA (`gitlab/gitlab-qa`) container and running the `QA::EE::Scenario::Test::Geo` scenario. Note that the Geo setup steps in the `QA::EE::Scenario::Test::Geo` scenario are skipped when testing a live Geo deployment.
589
+
590
+ **Required user properties:**
591
+
592
+ - The user must provide OAuth authorization on the secondary site before running Geo tests. This can be done via the authorization modal that appears after logging into the secondary node for the first time.
593
+
594
+ - Some Geo tests require the user to have Admin access level (for example, the Geo Nodes API tests)
595
+
596
+ **Required environment variables:**
597
+
598
+ - `GITLAB_QA_ACCESS_TOKEN`: A valid personal access token with the `api` scope.
599
+ This is used to retrieve the version that staging is currently running.
600
+ This can be found in the shared 1Password vault.
601
+
602
+ **Optional environment variables:**
603
+
604
+ - `GITLAB_QA_DEV_ACCESS_TOKEN`: A valid personal access token for the
605
+ `gitlab-qa-bot` on `dev.gitlab.org` with the `registry` scope.
606
+ This is used to pull the QA Docker image from the Omnibus GitLab `dev` Container Registry.
607
+ If the variable isn't present, the QA image from Docker Hub will be used.
608
+ This can be found in the shared 1Password vault.
609
+
610
+ Example:
611
+
612
+ ```
613
+ $ export GITLAB_QA_ACCESS_TOKEN=your_api_access_token
614
+ $ export GITLAB_QA_DEV_ACCESS_TOKEN=your_dev_registry_access_token
615
+ $ export GITLAB_USERNAME="gitlab-qa"
616
+ $ export GITLAB_PASSWORD="$GITLAB_QA_PASSWORD"
617
+
618
+ $ gitlab-qa Test::Instance::StagingGeo
619
+ ```
620
+
563
621
  ### `Test::Instance::Production`
564
622
 
565
623
  This scenario functions the same as `Test::Instance::Staging`
@@ -618,6 +676,40 @@ $ export QA_ADDITIONAL_REPOSITORY_STORAGE=secondary
618
676
  $ gitlab-qa Test::Instance::RepositoryStorage
619
677
  ```
620
678
 
679
+ ### `Test::Instance::Airgapped`
680
+
681
+ This scenario will run tests from the test suite against an airgapped instance.
682
+ The airgapped instance is set up by using `iptables` in the GitLab container to block network traffic other than testable ports, and by using runners
683
+ in a shared internal network.
684
+
685
+ Example:
686
+
687
+ ```
688
+ # For EE
689
+ $ export EE_LICENSE=$(cat /path/to/gitlab_license)
690
+
691
+ $ gitlab-qa Test::Instance::Airgapped EE -- --tag smoke
692
+ ```
693
+
694
+ ### `Test::Instance::Geo EE|<full image address>:nightly|latest|any_tag http://geo-primary.gitlab http://geo-secondary.gitlab`
695
+
696
+ This scenario will run tests tagged `:geo` against a live Geo deployment, by spinning up a GitLab QA (`gitlab/gitlab-qa`)
697
+ container and running the `QA::EE::Scenario::Test::Geo` scenario. Note that the Geo setup steps in the `QA::EE::Scenario::Test::Geo` scenario are skipped when testing a live Geo deployment. The URLs for the primary site and secondary site of the live Geo deployment must be provided as command line arguments.
698
+
699
+ **Required user properties:**
700
+
701
+ - The user must provide OAuth authorization on the secondary site before running Geo tests. This can be done via the authorization modal that appears after signing into the secondary node for the first time.
702
+
703
+ - Some Geo tests require the user to have Admin access level (for example, the Geo Nodes API tests)
704
+
705
+ Example:
706
+
707
+ ```
708
+ $ export GITLAB_USERNAME="gitlab-qa"
709
+ $ export GITLAB_PASSWORD="$GITLAB_QA_PASSWORD"
710
+
711
+ $ gitlab-qa Test::Instance::Geo EE https://primary.gitlab.com https://secondary.gitlab.com
712
+ ```
621
713
  ----
622
714
 
623
715
  [Back to README.md](../README.md)
@@ -29,6 +29,7 @@ module Gitlab
29
29
  autoload :Release, 'gitlab/qa/scenario/test/instance/release'
30
30
  autoload :Geo, 'gitlab/qa/scenario/test/instance/geo'
31
31
  autoload :StagingGeo, 'gitlab/qa/scenario/test/instance/staging_geo'
32
+ autoload :Airgapped, 'gitlab/qa/scenario/test/instance/airgapped'
32
33
  end
33
34
 
34
35
  module Omnibus
@@ -53,7 +54,7 @@ module Gitlab
53
54
  autoload :Praefect, 'gitlab/qa/scenario/test/integration/praefect'
54
55
  autoload :Elasticsearch, 'gitlab/qa/scenario/test/integration/elasticsearch'
55
56
  autoload :SMTP, 'gitlab/qa/scenario/test/integration/smtp'
56
- autoload :GitalyHA, 'gitlab/qa/scenario/test/integration/gitaly_ha'
57
+ autoload :GitalyCluster, 'gitlab/qa/scenario/test/integration/gitaly_cluster'
57
58
  autoload :Jira, 'gitlab/qa/scenario/test/integration/jira'
58
59
  end
59
60
 
@@ -5,7 +5,7 @@ module Gitlab
5
5
  include Scenario::Actable
6
6
 
7
7
  attr_reader :docker
8
- attr_accessor :volumes, :network, :environment
8
+ attr_accessor :volumes, :network, :environment, :runner_network
9
9
  attr_writer :name, :exec_commands
10
10
 
11
11
  def initialize
@@ -42,6 +42,16 @@ module Gitlab
42
42
  end
43
43
 
44
44
  def instance
45
+ instance_no_teardown do
46
+ yield self if block_given?
47
+ end
48
+ ensure
49
+ teardown
50
+ end
51
+
52
+ alias_method :launch_and_teardown_instance, :instance
53
+
54
+ def instance_no_teardown
45
55
  prepare
46
56
  start
47
57
  reconfigure
@@ -49,24 +59,22 @@ module Gitlab
49
59
  process_exec_commands
50
60
 
51
61
  yield self if block_given?
52
- ensure
53
- teardown
54
62
  end
55
63
 
56
- alias_method :launch_and_teardown_instance, :instance
57
-
58
64
  def prepare
59
65
  prepare_docker_image
60
66
  prepare_network
61
67
  end
62
68
 
63
69
  def prepare_docker_image
64
- return if Runtime::Env.skip_pull?
65
-
66
70
  pull
67
71
  end
68
72
 
69
73
  def prepare_network
74
+ if runner_network && !docker.network_exists?(runner_network)
75
+ docker.network_create("--driver=bridge --internal #{runner_network}")
76
+ end
77
+
70
78
  return if docker.network_exists?(network)
71
79
 
72
80
  docker.network_create(network)
@@ -102,6 +110,17 @@ module Gitlab
102
110
  end
103
111
 
104
112
  def teardown
113
+ unless teardown?
114
+ puts "The orchestrated docker containers have not been removed."
115
+ docker.ps
116
+
117
+ return
118
+ end
119
+
120
+ teardown!
121
+ end
122
+
123
+ def teardown!
105
124
  assert_name!
106
125
 
107
126
  return unless docker.running?(name)
@@ -111,6 +130,8 @@ module Gitlab
111
130
  end
112
131
 
113
132
  def pull
133
+ return if Runtime::Env.skip_pull?
134
+
114
135
  docker.pull(image, tag)
115
136
  end
116
137
 
@@ -125,6 +146,10 @@ module Gitlab
125
146
  def assert_name!
126
147
  raise 'Invalid instance name!' unless name
127
148
  end
149
+
150
+ def teardown?
151
+ !Runtime::Scenario.attributes.include?(:teardown) || Runtime::Scenario.teardown
152
+ end
128
153
  end
129
154
  end
130
155
  end
@@ -11,7 +11,7 @@ module Gitlab
11
11
  extend Forwardable
12
12
 
13
13
  attr_reader :release
14
- attr_accessor :tls, :disable_animations, :skip_availability_check
14
+ attr_accessor :tls, :disable_animations, :skip_availability_check, :runner_network
15
15
  attr_writer :name, :relative_path
16
16
 
17
17
  def_delegators :release, :tag, :image, :edition
@@ -116,6 +116,7 @@ module Gitlab
116
116
  command << "--network-alias #{network_alias}"
117
117
  end
118
118
  end
119
+ Docker::Command.execute("network connect --alias #{name}.#{network} --alias #{name}.#{runner_network} #{runner_network} #{name}") if runner_network
119
120
  end
120
121
 
121
122
  def reconfigure
@@ -8,7 +8,7 @@ module Gitlab
8
8
  # the `qa/` directory located in GitLab CE / EE repositories.
9
9
  #
10
10
  class Specs < Scenario::Template
11
- attr_accessor :suite, :release, :network, :args, :volumes, :env
11
+ attr_accessor :suite, :release, :network, :args, :volumes, :env, :runner_network
12
12
 
13
13
  def initialize
14
14
  @docker = Docker::Engine.new
@@ -17,6 +17,8 @@ module Gitlab
17
17
  end
18
18
 
19
19
  def perform # rubocop:disable Metrics/AbcSize
20
+ return puts "Skipping tests." if skip_tests?
21
+
20
22
  raise ArgumentError unless [suite, release].all?
21
23
 
22
24
  @docker.login(**release.login_params) if release.login_params
@@ -25,23 +27,53 @@ module Gitlab
25
27
 
26
28
  name = "#{release.project_name}-qa-#{SecureRandom.hex(4)}"
27
29
 
28
- @docker.run(release.qa_image, release.qa_tag, suite, *args) do |command|
29
- command << "-t --rm --net=#{network || 'bridge'}"
30
+ feature_flag_sets = []
30
31
 
31
- env.merge(Runtime::Env.variables).each do |key, value|
32
- command.env(key, value)
33
- end
32
+ # When `args` includes `[..., "--disable-feature", "a", "--enable-feature", "b", ...]`
33
+ # `feature_flag_sets` will be set to `[["--disable-feature", "a"], ["--enable-feature", "b"]]`
34
+ # This will result in tests running twice, once with each feature.
35
+ while (index = args&.index { |x| x =~ /--.*-feature/ })
36
+ feature_flag_sets << args.slice!(index, 2)
37
+ end
34
38
 
35
- command.volume('/var/run/docker.sock', '/var/run/docker.sock')
36
- command.volume(File.join(Runtime::Env.host_artifacts_dir, name), File.join(Docker::Volumes::QA_CONTAINER_WORKDIR, 'tmp'))
39
+ # When `args` do not have either "--disable-feature" or "--enable-feature", we
40
+ # add [] so that test is run exactly once.
41
+ feature_flag_sets << [] unless feature_flag_sets.any?
37
42
 
38
- @volumes.to_h.each do |to, from|
39
- command.volume(to, from)
40
- end
43
+ feature_flag_sets.each do |feature_flag_set|
44
+ @docker.run(release.qa_image, release.qa_tag, suite, *args_with_flags(args, feature_flag_set)) do |command|
45
+ command << "-t --rm --net=#{network || 'bridge'}"
41
46
 
42
- command.name(name)
47
+ env.merge(Runtime::Env.variables).each do |key, value|
48
+ command.env(key, value)
49
+ end
50
+
51
+ command.volume('/var/run/docker.sock', '/var/run/docker.sock')
52
+ command.volume(File.join(Runtime::Env.host_artifacts_dir, name), File.join(Docker::Volumes::QA_CONTAINER_WORKDIR, 'tmp'))
53
+
54
+ @volumes.to_h.each do |to, from|
55
+ command.volume(to, from)
56
+ end
57
+
58
+ command.name(name)
59
+ end
43
60
  end
44
61
  end
62
+
63
+ private
64
+
65
+ def args_with_flags(args, feature_flag_set)
66
+ return args if feature_flag_set.empty?
67
+
68
+ puts "Running with feature flag: #{feature_flag_set.join(' ')}"
69
+
70
+ args_with_f = args.dup
71
+ args_with_f.insert(1, *feature_flag_set)
72
+ end
73
+
74
+ def skip_tests?
75
+ Runtime::Scenario.attributes.include?(:run_tests) && !Runtime::Scenario.run_tests
76
+ end
45
77
  end
46
78
  end
47
79
  end