knapsack_pro 2.11.0 → 2.16.0
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/CHANGELOG.md +40 -0
- data/README.md +35 -1600
- data/lib/knapsack_pro/adapters/rspec_adapter.rb +12 -2
- data/lib/knapsack_pro/allocator.rb +1 -1
- data/lib/knapsack_pro/queue_allocator.rb +1 -1
- data/lib/knapsack_pro/runners/queue/rspec_runner.rb +23 -4
- data/lib/knapsack_pro/tracker.rb +13 -4
- data/lib/knapsack_pro/version.rb +1 -1
- data/spec/knapsack_pro/adapters/rspec_adapter_spec.rb +30 -12
- data/spec/knapsack_pro/runners/queue/rspec_runner_spec.rb +37 -7
- data/spec/knapsack_pro/tracker_spec.rb +4 -2
- metadata +2 -2
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA256:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: 534699a91609a71a2621b9625a3ff555a58bf385728be90adce4cfe6d6b771dd
|
|
4
|
+
data.tar.gz: 913fc4a85433a50f3639bdc087995f9dc5e482b33d7768cfdb84c0f767326c2c
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: da5e5ef1c262d97b6214eddff32c8aa2031fe122ad1597a1cf4bd2a939fe82f9fd6b0c7287861f5373521f731318a0e856a331220ae0076eef9cdf8323ab0548
|
|
7
|
+
data.tar.gz: 2e058c2c3b82c9c97481ab84873c652fb3ab4844521c4746efeaca2dccca8b265b58ba427d44af56b130769bf56c6cbacd84b516b1e6b44d099a8a33b2ef340b
|
data/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,45 @@
|
|
|
1
1
|
# Change Log
|
|
2
2
|
|
|
3
|
+
### 2.16.0
|
|
4
|
+
|
|
5
|
+
* Improve test time execution tracking for RSpec
|
|
6
|
+
|
|
7
|
+
https://github.com/KnapsackPro/knapsack_pro-ruby/pull/145
|
|
8
|
+
|
|
9
|
+
https://github.com/KnapsackPro/knapsack_pro-ruby/compare/v2.15.0...v2.16.0
|
|
10
|
+
|
|
11
|
+
### 2.15.0
|
|
12
|
+
|
|
13
|
+
* Do not allow to use the RSpec tag option together with the RSpec split by test examples feature
|
|
14
|
+
|
|
15
|
+
https://github.com/KnapsackPro/knapsack_pro-ruby/pull/139
|
|
16
|
+
|
|
17
|
+
https://github.com/KnapsackPro/knapsack_pro-ruby/compare/v2.14.0...v2.15.0
|
|
18
|
+
|
|
19
|
+
### 2.14.0
|
|
20
|
+
|
|
21
|
+
* Track time spend in RSpec context hook
|
|
22
|
+
|
|
23
|
+
https://github.com/KnapsackPro/knapsack_pro-ruby/pull/143
|
|
24
|
+
|
|
25
|
+
https://github.com/KnapsackPro/knapsack_pro-ruby/compare/v2.13.0...v2.14.0
|
|
26
|
+
|
|
27
|
+
### 2.13.0
|
|
28
|
+
|
|
29
|
+
* Update FAQ links in `knapsack_pro` warnings and remove FAQ from readme
|
|
30
|
+
|
|
31
|
+
https://github.com/KnapsackPro/knapsack_pro-ruby/pull/142
|
|
32
|
+
|
|
33
|
+
https://github.com/KnapsackPro/knapsack_pro-ruby/compare/v2.12.0...v2.13.0
|
|
34
|
+
|
|
35
|
+
### 2.12.0
|
|
36
|
+
|
|
37
|
+
* Use 0 seconds as a default test file time execution instead of 0.1s because Knapsack Pro API already accepts 0 seconds value
|
|
38
|
+
|
|
39
|
+
https://github.com/KnapsackPro/knapsack_pro-ruby/pull/140
|
|
40
|
+
|
|
41
|
+
https://github.com/KnapsackPro/knapsack_pro-ruby/compare/v2.11.0...v2.12.0
|
|
42
|
+
|
|
3
43
|
### 2.11.0
|
|
4
44
|
|
|
5
45
|
* Verify test runner adapter bind method is called to track test files time execution and ensure `tmp/knapsack_pro` directory is not removed accidentally
|
data/README.md
CHANGED
|
@@ -42,11 +42,7 @@ The knapsack_pro has also [queue mode](#queue-mode) to get an optimal test suite
|
|
|
42
42
|
|
|
43
43
|
## FAQ
|
|
44
44
|
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
__OLD:__ This README also contains FAQ questions but we keep adding new info only to our new FAQ page mentioned above.
|
|
48
|
-
|
|
49
|
-
We keep this old FAQ in README to not break old links spread across the web. You can see old FAQ list of questions for common problems and tips in below [Table of Contents](#table-of-contents). Scroll 1 page down and you will see the FAQ in the table of contents.
|
|
45
|
+
[FAQ for knapsack_pro gem can be found here](https://knapsackpro.com/faq/knapsack_pro_client/knapsack_pro_ruby).
|
|
50
46
|
|
|
51
47
|
# Requirements
|
|
52
48
|
|
|
@@ -72,8 +68,9 @@ We keep this old FAQ in README to not break old links spread across the web. You
|
|
|
72
68
|
- [Set API key token](#set-api-key-token)
|
|
73
69
|
- [Set knapsack_pro command to execute tests](#set-knapsack_pro-command-to-execute-tests)
|
|
74
70
|
- [Repository adapter (How to set up 3 of 3)](#repository-adapter-how-to-set-up-3-of-3)
|
|
75
|
-
- [
|
|
76
|
-
- [When should you set global variable `KNAPSACK_PRO_REPOSITORY_ADAPTER=git` (
|
|
71
|
+
- [By default `KNAPSACK_PRO_REPOSITORY_ADAPTER` environment variable is undefined](#by-default-knapsack_pro_repository_adapter-environment-variable-is-undefined)
|
|
72
|
+
- [When should you set global variable `KNAPSACK_PRO_REPOSITORY_ADAPTER=git` (when CI provider is not supported and you use git)](#when-should-you-set-global-variable-knapsack_pro_repository_adaptergit-when-ci-provider-is-not-supported-and-you-use-git)
|
|
73
|
+
- [When you don't use git](#when-you-dont-use-git)
|
|
77
74
|
- [Queue Mode](#queue-mode)
|
|
78
75
|
- [How does queue mode work?](#how-does-queue-mode-work)
|
|
79
76
|
- [How to use queue mode?](#how-to-use-queue-mode)
|
|
@@ -84,7 +81,6 @@ We keep this old FAQ in README to not break old links spread across the web. You
|
|
|
84
81
|
- [Supported test runners in queue mode](#supported-test-runners-in-queue-mode)
|
|
85
82
|
- [Split test files by test cases](#split-test-files-by-test-cases)
|
|
86
83
|
- [RSpec split test files by test examples (by individual `it`s)](#rspec-split-test-files-by-test-examples-by-individual-its)
|
|
87
|
-
- [Why I see error: Don't know how to build task 'knapsack_pro:rspec_test_example_detector'?](#why-i-see-error-dont-know-how-to-build-task-knapsack_prorspec_test_example_detector)
|
|
88
84
|
- [How to manually define a list of slow test files to be split by test cases](#how-to-manually-define-a-list-of-slow-test-files-to-be-split-by-test-cases)
|
|
89
85
|
- [Extra configuration for CI server](#extra-configuration-for-ci-server)
|
|
90
86
|
- [Info about ENV variables](#info-about-env-variables)
|
|
@@ -124,86 +120,6 @@ We keep this old FAQ in README to not break old links spread across the web. You
|
|
|
124
120
|
- [Info for Jenkins users](#info-for-jenkins-users)
|
|
125
121
|
- [Info for GitHub Actions users](#info-for-github-actions-users)
|
|
126
122
|
- [Info for Codefresh.io users](#info-for-codefreshio-users)
|
|
127
|
-
- [FAQ](#faq)
|
|
128
|
-
- [Common problems](#common-problems)
|
|
129
|
-
- [Why I see API error commit_hash parameter is required?](#why-i-see-api-error-commit_hash-parameter-is-required)
|
|
130
|
-
- [Why I see `LoadError: cannot load such file -- spec_helper`?](#why-i-see-loaderror-cannot-load-such-file----spec_helper)
|
|
131
|
-
- [Why my CI build fails when I use Test::Unit even when all tests passed?](#why-my-ci-build-fails-when-i-use-testunit-even-when-all-tests-passed)
|
|
132
|
-
- [Why I see HEAD as branch name in user dashboard for Build metrics for my API token?](#why-i-see-head-as-branch-name-in-user-dashboard-for-build-metrics-for-my-api-token)
|
|
133
|
-
- [Why Capybara feature tests randomly fail when using CI parallelisation?](#why-capybara-feature-tests-randomly-fail-when-using-ci-parallelisation)
|
|
134
|
-
- [Why knapsack_pro freezes / hangs my CI (for instance Travis)?](#why-knapsack_pro-freezes--hangs-my-ci-for-instance-travis)
|
|
135
|
-
- [Why tests hitting external API fail?](#why-tests-hitting-external-api-fail)
|
|
136
|
-
- [Why green test suite for Cucumber 2.99 tests always fails with `invalid option: --require`?](#why-green-test-suite-for-cucumber-299-tests-always-fails-with-invalid-option---require)
|
|
137
|
-
- [Queue Mode problems](#queue-mode-problems)
|
|
138
|
-
- [Why when I use Queue Mode for RSpec then my tests fail?](#why-when-i-use-queue-mode-for-rspec-then-my-tests-fail)
|
|
139
|
-
- [Why when I use Queue Mode for RSpec then FactoryBot/FactoryGirl tests fail?](#why-when-i-use-queue-mode-for-rspec-then-factorybotfactorygirl-tests-fail)
|
|
140
|
-
- [Why when I use Queue Mode for RSpec then my rake tasks are run twice?](#why-when-i-use-queue-mode-for-rspec-then-my-rake-tasks-are-run-twice)
|
|
141
|
-
- [Why when I use Queue Mode for RSpec then I see error `superclass mismatch for class`?](#why-when-i-use-queue-mode-for-rspec-then-i-see-error-superclass-mismatch-for-class)
|
|
142
|
-
- [Why when I use Queue Mode for RSpec then `.rspec` config is ignored?](#why-when-i-use-queue-mode-for-rspec-then-rspec-config-is-ignored)
|
|
143
|
-
- [Why I don't see collected time execution data for my build in user dashboard?](#why-i-dont-see-collected-time-execution-data-for-my-build-in-user-dashboard)
|
|
144
|
-
- [Why all test files have 0.1s time execution for my CI build in user dashboard?](#why-all-test-files-have-01s-time-execution-for-my-ci-build-in-user-dashboard)
|
|
145
|
-
- [Why when I use Queue Mode for RSpec and test fails then I see multiple times info about failed test in RSpec result?](#why-when-i-use-queue-mode-for-rspec-and-test-fails-then-i-see-multiple-times-info-about-failed-test-in-rspec-result)
|
|
146
|
-
- [Why when I use Queue Mode for RSpec then I see multiple times the same pending tests?](#why-when-i-use-queue-mode-for-rspec-then-i-see-multiple-times-the-same-pending-tests)
|
|
147
|
-
- [Does in Queue Mode the RSpec is initialized many times that causes Rails load over and over again?](#does-in-queue-mode-the-rspec-is-initialized-many-times-that-causes-rails-load-over-and-over-again)
|
|
148
|
-
- [Why my tests are executed twice in queue mode? Why CI node runs whole test suite again?](#why-my-tests-are-executed-twice-in-queue-mode-why-ci-node-runs-whole-test-suite-again)
|
|
149
|
-
- [How to fix capybara-screenshot fail with `SystemStackError: stack level too deep` when using Queue Mode for RSpec?](#how-to-fix-capybara-screenshot-fail-with-systemstackerror-stack-level-too-deep-when-using-queue-mode-for-rspec)
|
|
150
|
-
- [Parallel tests Cucumber and RSpec with Cucumber failures exit CI node early leaving fewer CI nodes to finish RSpec Queue.](#parallel-tests-cucumber-and-rspec-with-cucumber-failures-exit-ci-node-early-leaving-fewer-ci-nodes-to-finish-rspec-queue)
|
|
151
|
-
- [Why when I reran the same build (same commit hash, etc) on Codeship then no tests would get executed in Queue Mode?](#why-when-i-reran-the-same-build-same-commit-hash-etc-on-codeship-then-no-tests-would-get-executed-in-queue-mode)
|
|
152
|
-
- [Why knapsack_pro hangs / freezes / is stale i.e. for Codeship in Queue Mode?](#why-knapsack_pro-hangs--freezes--is-stale-ie-for-codeship-in-queue-mode)
|
|
153
|
-
- [How to find seed in RSpec output when I use Queue Mode for RSpec?](#how-to-find-seed-in-rspec-output-when-i-use-queue-mode-for-rspec)
|
|
154
|
-
- [How to configure puffing-billy gem with Knapsack Pro Queue Mode?](#how-to-configure-puffing-billy-gem-with-knapsack-pro-queue-mode)
|
|
155
|
-
- [General questions](#general-questions)
|
|
156
|
-
- [How to run tests for particular CI node in your development environment](#how-to-run-tests-for-particular-ci-node-in-your-development-environment)
|
|
157
|
-
- [for knapsack_pro regular mode](#for-knapsack_pro-regular-mode)
|
|
158
|
-
- [for knapsack_pro queue mode](#for-knapsack_pro-queue-mode)
|
|
159
|
-
- [What happens when Knapsack Pro API is not available/not reachable temporarily?](#what-happens-when-knapsack-pro-api-is-not-availablenot-reachable-temporarily)
|
|
160
|
-
- [for knapsack_pro regular mode](#for-knapsack_pro-regular-mode-1)
|
|
161
|
-
- [for knapsack_pro queue mode](#for-knapsack_pro-queue-mode-1)
|
|
162
|
-
- [How can I change log level?](#how-can-i-change-log-level)
|
|
163
|
-
- [How to write knapsack_pro logs to a file?](#how-to-write-knapsack_pro-logs-to-a-file)
|
|
164
|
-
- [set directory where to write log file (option 1 - recommended)](#set-directory-where-to-write-log-file-option-1---recommended)
|
|
165
|
-
- [set custom logger config (option 2)](#set-custom-logger-config-option-2)
|
|
166
|
-
- [How to preserve logs on my CI after CI build completed?](#how-to-preserve-logs-on-my-ci-after-ci-build-completed)
|
|
167
|
-
- [How to split tests based on test level instead of test file level?](#how-to-split-tests-based-on-test-level-instead-of-test-file-level)
|
|
168
|
-
- [A. Create multiple small test files](#a-create-multiple-small-test-files)
|
|
169
|
-
- [B. Use tags to mark set of tests in particular test file](#b-use-tags-to-mark-set-of-tests-in-particular-test-file)
|
|
170
|
-
- [How to make knapsack_pro works for forked repositories of my project?](#how-to-make-knapsack_pro-works-for-forked-repositories-of-my-project)
|
|
171
|
-
- [How to use junit formatter?](#how-to-use-junit-formatter)
|
|
172
|
-
- [How to use junit formatter with knapsack_pro regular mode?](#how-to-use-junit-formatter-with-knapsack_pro-regular-mode)
|
|
173
|
-
- [How to use junit formatter with knapsack_pro queue mode?](#how-to-use-junit-formatter-with-knapsack_pro-queue-mode)
|
|
174
|
-
- [How to use junit formatter with knapsack_pro queue mode when CI nodes use common local drive?](#how-to-use-junit-formatter-with-knapsack_pro-queue-mode-when-ci-nodes-use-common-local-drive)
|
|
175
|
-
- [Why `tmp/rspec_final_results.xml` is corrupted when I use junit formatter with knapsack_pro queue mode?](#why-tmprspec_final_resultsxml-is-corrupted-when-i-use-junit-formatter-with-knapsack_pro-queue-mode)
|
|
176
|
-
- [How to use junit formatter with knapsack_pro queue mode in Cucumber?](#how-to-use-junit-formatter-with-knapsack_pro-queue-mode-in-cucumber)
|
|
177
|
-
- [How to use JSON formatter for RSpec?](#how-to-use-json-formatter-for-rspec)
|
|
178
|
-
- [How to use RSpec JSON formatter with knapsack_pro Queue Mode?](#how-to-use-rspec-json-formatter-with-knapsack_pro-queue-mode)
|
|
179
|
-
- [How to use RSpec JSON formatter with knapsack_pro Queue Mode when CI nodes use common local drive?](#how-to-use-rspec-json-formatter-with-knapsack_pro-queue-mode-when-ci-nodes-use-common-local-drive)
|
|
180
|
-
- [How many API keys I need?](#how-many-api-keys-i-need)
|
|
181
|
-
- [What is optimal order of test commands?](#what-is-optimal-order-of-test-commands)
|
|
182
|
-
- [How to set `before(:suite)` and `after(:suite)` RSpec hooks in Queue Mode (Percy.io example)?](#how-to-set-beforesuite-and-aftersuite-rspec-hooks-in-queue-mode-percyio-example)
|
|
183
|
-
- [percy-capybara gem version < 4 (old)](#percy-capybara-gem-version--4-old)
|
|
184
|
-
- [percy-capybara gem version >= 4](#percy-capybara-gem-version--4)
|
|
185
|
-
- [How to call `before(:suite)` and `after(:suite)` RSpec hooks only once in Queue Mode?](#how-to-call-beforesuite-and-aftersuite-rspec-hooks-only-once-in-queue-mode)
|
|
186
|
-
- [What hooks are supported in Queue Mode?](#what-hooks-are-supported-in-queue-mode)
|
|
187
|
-
- [How to run knapsack_pro with parallel_tests gem?](#how-to-run-knapsack_pro-with-parallel_tests-gem)
|
|
188
|
-
- [Should I use parallel_tests gem (what are pitfalls)?](#should-i-use-parallel_tests-gem-what-are-pitfalls)
|
|
189
|
-
- [parallel_tests with knapsack_pro on parallel CI nodes](#parallel_tests-with-knapsack_pro-on-parallel-ci-nodes)
|
|
190
|
-
- [parallel_tests with knapsack_pro on single CI machine](#parallel_tests-with-knapsack_pro-on-single-ci-machine)
|
|
191
|
-
- [How to retry failed tests (flaky tests)?](#how-to-retry-failed-tests-flaky-tests)
|
|
192
|
-
- [How can I run tests from multiple directories?](#how-can-i-run-tests-from-multiple-directories)
|
|
193
|
-
- [Why I don't see all test files being recorded in user dashboard](#why-i-dont-see-all-test-files-being-recorded-in-user-dashboard)
|
|
194
|
-
- [Why when I use 2 different CI providers then not all test files are executed?](#why-when-i-use-2-different-ci-providers-then-not-all-test-files-are-executed)
|
|
195
|
-
- [How to run only RSpec feature tests or non feature tests?](#how-to-run-only-rspec-feature-tests-or-non-feature-tests)
|
|
196
|
-
- [How to exclude tests from running them?](#how-to-exclude-tests-from-running-them)
|
|
197
|
-
- [How to run a specific list of test files or only some tests from test file?](#how-to-run-a-specific-list-of-test-files-or-only-some-tests-from-test-file)
|
|
198
|
-
- [How to run knapsack_pro only on a few parallel CI nodes instead of all?](#how-to-run-knapsack_pro-only-on-a-few-parallel-ci-nodes-instead-of-all)
|
|
199
|
-
- [How to use CodeClimate with knapsack_pro?](#how-to-use-codeclimate-with-knapsack_pro)
|
|
200
|
-
- [How to use simplecov in Queue Mode?](#how-to-use-simplecov-in-queue-mode)
|
|
201
|
-
- [Do I need to use separate API token for Queue Mode and Regular Mode?](#do-i-need-to-use-separate-api-token-for-queue-mode-and-regular-mode)
|
|
202
|
-
- [How to stop running tests on the first failed test (fail fast tests in RSpec)?](#how-to-stop-running-tests-on-the-first-failed-test-fail-fast-tests-in-rspec)
|
|
203
|
-
- [Questions around data usage and security](#questions-around-data-usage-and-security)
|
|
204
|
-
- [What data is sent to your servers?](#what-data-is-sent-to-your-servers)
|
|
205
|
-
- [How is that data secured?](#how-is-that-data-secured)
|
|
206
|
-
- [Who has access to the data?](#who-has-access-to-the-data)
|
|
207
123
|
- [Gem tests](#gem-tests)
|
|
208
124
|
- [Spec](#spec)
|
|
209
125
|
- [Contributing](#contributing)
|
|
@@ -375,12 +291,12 @@ KnapsackPro.logger = Logger.new(STDOUT)
|
|
|
375
291
|
KnapsackPro.logger.level = Logger::DEBUG
|
|
376
292
|
```
|
|
377
293
|
|
|
378
|
-
Debug is default log level and it is recommended. [Read more](
|
|
294
|
+
Debug is default log level and it is recommended. [Read more](https://knapsackpro.com/faq/question/how-can-i-change-log-level).
|
|
379
295
|
|
|
380
296
|
Note your own logger is configured in `spec_helper.rb` or `rails_helper.rb` and it will start working when those files will be loaded.
|
|
381
297
|
It means the very first request to Knapsack Pro API will be log to `STDOUT` using logger built into knapsack_pro instead of your custom logger.
|
|
382
298
|
|
|
383
|
-
If you want to change log level globally than just for your custom log level, please [see this](
|
|
299
|
+
If you want to change log level globally than just for your custom log level, please [see this](https://knapsackpro.com/faq/question/how-can-i-change-log-level).
|
|
384
300
|
|
|
385
301
|
### Setup your CI server (How to set up 2 of 3)
|
|
386
302
|
|
|
@@ -438,11 +354,11 @@ KNAPSACK_PRO_TEST_FILE_PATTERN="directory_with_features/**{,/*/**}/*.feature" KN
|
|
|
438
354
|
|
|
439
355
|
__Tip:__ If you use one of the supported CI providers then instead of the above steps you should [take a look at this](#supported-ci-providers).
|
|
440
356
|
|
|
441
|
-
__Tip 2:__ If you use one of unsupported CI providers ([here is list of supported CI providers](#supported-ci-providers)) then you should [set KNAPSACK_PRO_REPOSITORY_ADAPTER=git](#when-should-you-set-global-variable-knapsack_pro_repository_adaptergit-
|
|
357
|
+
__Tip 2:__ If you use one of unsupported CI providers ([here is list of supported CI providers](#supported-ci-providers)) then you should [set KNAPSACK_PRO_REPOSITORY_ADAPTER=git](#when-should-you-set-global-variable-knapsack_pro_repository_adaptergit-when-ci-provider-is-not-supported-and-you-use-git).
|
|
442
358
|
|
|
443
359
|
### Repository adapter (How to set up 3 of 3)
|
|
444
360
|
|
|
445
|
-
####
|
|
361
|
+
#### By default `KNAPSACK_PRO_REPOSITORY_ADAPTER` environment variable is undefined
|
|
446
362
|
|
|
447
363
|
By default `KNAPSACK_PRO_REPOSITORY_ADAPTER` variable has no value so knapsack_pro will try to get info about branch name and commit hash from [supported CI](#supported-ci-providers) (CI providers have branch, commit, project directory stored as environment variables). In case when you use other CI provider like Jenkins then please set below variables on your own.
|
|
448
364
|
|
|
@@ -452,12 +368,20 @@ By default `KNAPSACK_PRO_REPOSITORY_ADAPTER` variable has no value so knapsack_p
|
|
|
452
368
|
|
|
453
369
|
You can also use git as repository adapter to determine branch and commit hash, please see below section.
|
|
454
370
|
|
|
455
|
-
#### When should you set global variable `KNAPSACK_PRO_REPOSITORY_ADAPTER=git` (
|
|
371
|
+
#### When should you set global variable `KNAPSACK_PRO_REPOSITORY_ADAPTER=git` (when CI provider is not supported and you use git)
|
|
456
372
|
|
|
457
373
|
`KNAPSACK_PRO_REPOSITORY_ADAPTER` - When it has the value `git`, your local version of git on CI server will be used to get the branch name and commit hash. You also need to set `KNAPSACK_PRO_PROJECT_DIR` with the project directory path.
|
|
458
374
|
|
|
459
375
|
`KNAPSACK_PRO_PROJECT_DIR` - Path to the project on the CI node, for instance `/home/ubuntu/my-app-repository`. It should be the top-level directory of your repository.
|
|
460
376
|
|
|
377
|
+
#### When you don't use git
|
|
378
|
+
|
|
379
|
+
If your CI provider does not expose commit hash and branch name through environment variables, then `knapsack_pro` gem does not know these values.
|
|
380
|
+
You can manually set the values of the current commit hash and branch name in the environment variables:
|
|
381
|
+
|
|
382
|
+
* `KNAPSACK_PRO_COMMIT_HASH` - commit hash.
|
|
383
|
+
* `KNAPSACK_PRO_BRANCH` - branch name.
|
|
384
|
+
|
|
461
385
|
## Queue Mode
|
|
462
386
|
|
|
463
387
|
knapsack_pro has a built-in queue mode designed to determine the optimal test suite split even when there is an unpredictably longer time execution of test files on one node (e.g. by
|
|
@@ -507,11 +431,11 @@ The second CI build should have optimal test suite split with faster tests distr
|
|
|
507
431
|
|
|
508
432
|
__Please ensure you have explicitly set `RAILS_ENV=test` on your CI nodes.__
|
|
509
433
|
|
|
510
|
-
If you use the capybara-screenshot gem then please [follow this step](
|
|
434
|
+
If you use the capybara-screenshot gem then please [follow this step](https://knapsackpro.com/faq/question/how-to-fix-capybara-screenshot-fail-with-systemstackerror-stack-level-too-deep-when-using-queue-mode-for-rspec).
|
|
511
435
|
|
|
512
|
-
If you use the rspec_junit_formatter gem then please [follow this step](#how-to-use-junit-formatter-with-knapsack_pro-queue-mode).
|
|
436
|
+
If you use the rspec_junit_formatter gem then please [follow this step](https://knapsackpro.com/faq/question/how-to-use-junit-formatter#how-to-use-junit-formatter-with-knapsack_pro-queue-mode).
|
|
513
437
|
|
|
514
|
-
If your test suite is very long and the RSpec output is too long for your CI node then you can set log level `KNAPSACK_PRO_LOG_LEVEL=info` to don't show debug messages in RSpec output. [Read more about log level](
|
|
438
|
+
If your test suite is very long and the RSpec output is too long for your CI node then you can set log level `KNAPSACK_PRO_LOG_LEVEL=info` to don't show debug messages in RSpec output. [Read more about log level](https://knapsackpro.com/faq/question/how-can-i-change-log-level).
|
|
515
439
|
|
|
516
440
|
### Additional info about queue mode
|
|
517
441
|
|
|
@@ -575,7 +499,7 @@ There might be some cached test suite splits for git commits you have run in pas
|
|
|
575
499
|
[knapsack_pro] {"queue_name"=>"retry-dead-ci-node:queue-id", "test_files"=>[{"path"=>"spec/foo_spec.rb", "time_execution"=>1.23}]}
|
|
576
500
|
```
|
|
577
501
|
|
|
578
|
-
* To [reproduce tests executed on CI node](#for-knapsack_pro-queue-mode) in development environment please see FAQ.
|
|
502
|
+
* To [reproduce tests executed on CI node](https://knapsackpro.com/faq/question/how-to-run-tests-for-particular-ci-node-in-your-development-environment#for-knapsack_pro-queue-mode) in development environment please see FAQ.
|
|
579
503
|
|
|
580
504
|
#### KNAPSACK_PRO_MODIFY_DEFAULT_RSPEC_FORMATTERS (hide duplicated summary of pending and failed tests)
|
|
581
505
|
|
|
@@ -609,6 +533,8 @@ Knapsack Pro API provides recorded timing of test files from your previously rec
|
|
|
609
533
|
|
|
610
534
|
### RSpec split test files by test examples (by individual `it`s)
|
|
611
535
|
|
|
536
|
+
Read more about [this feature](https://knapsackpro.com/faq/question/how-to-split-slow-rspec-test-files-by-test-examples-by-individual-it) and [common problems here](https://knapsackpro.com/faq/question/how-to-split-slow-rspec-test-files-by-test-examples-by-individual-it#common-problems).
|
|
537
|
+
|
|
612
538
|
> ❗ __RSpec requirement:__ You need `RSpec >= 3.3.0` in order to use this feature.
|
|
613
539
|
|
|
614
540
|
In order to split RSpec slow test files by test examples across parallel CI nodes you need to set environment variable:
|
|
@@ -619,16 +545,6 @@ KNAPSACK_PRO_RSPEC_SPLIT_BY_TEST_EXAMPLES=true
|
|
|
619
545
|
|
|
620
546
|
Thanks to that your CI build speed can be faster. We recommend using this feature with [Queue Mode](https://youtu.be/hUEB1XDKEFY) to ensure parallel CI nodes finish work at a similar time which gives you the shortest CI build time.
|
|
621
547
|
|
|
622
|
-
#### Why I see error: Don't know how to build task 'knapsack_pro:rspec_test_example_detector'?
|
|
623
|
-
|
|
624
|
-
If you will see error like:
|
|
625
|
-
|
|
626
|
-
```
|
|
627
|
-
Don't know how to build task 'knapsack_pro:rspec_test_example_detector' (See the list of available tasks with `rake --tasks`)
|
|
628
|
-
```
|
|
629
|
-
|
|
630
|
-
It probably means bundler can't find the rake task. You can try to remove the default prefix `bundle exec` used by knapsack_pro gem by setting `KNAPSACK_PRO_RSPEC_TEST_EXAMPLE_DETECTOR_PREFIX=""`.
|
|
631
|
-
|
|
632
548
|
### How to manually define a list of slow test files to be split by test cases
|
|
633
549
|
|
|
634
550
|
If you don't want to rely on a list of test files from Knapsack Pro API to determine slow test files that should be split by test cases then you can define your own list of slow test files.
|
|
@@ -857,6 +773,7 @@ Note: there are a few branch names that won't be encrypted because we use them a
|
|
|
857
773
|
* dev
|
|
858
774
|
* master
|
|
859
775
|
* staging
|
|
776
|
+
* [see full list of encryption excluded branch names](https://github.com/KnapsackPro/knapsack_pro-ruby/blob/master/lib/knapsack_pro/crypto/branch_encryptor.rb#L4)
|
|
860
777
|
|
|
861
778
|
#### How to debug branch names?
|
|
862
779
|
|
|
@@ -876,43 +793,7 @@ $ KNAPSACK_PRO_SALT=xxx bundle exec rake knapsack_pro:encrypted_branch_names[not
|
|
|
876
793
|
|
|
877
794
|
If you are using circleci.com you can omit `KNAPSACK_PRO_CI_NODE_TOTAL` and `KNAPSACK_PRO_CI_NODE_INDEX`. Knapsack Pro will use `CIRCLE_NODE_TOTAL` and `CIRCLE_NODE_INDEX` provided by CircleCI.
|
|
878
795
|
|
|
879
|
-
Here is an example for test configuration in your
|
|
880
|
-
|
|
881
|
-
```yaml
|
|
882
|
-
# CircleCI 1.0
|
|
883
|
-
|
|
884
|
-
machine:
|
|
885
|
-
environment:
|
|
886
|
-
# Tokens should be set in CircleCI settings to avoid expose tokens in build logs
|
|
887
|
-
# KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC: rspec-token
|
|
888
|
-
# KNAPSACK_PRO_TEST_SUITE_TOKEN_CUCUMBER: cucumber-token
|
|
889
|
-
# KNAPSACK_PRO_TEST_SUITE_TOKEN_MINITEST: minitest-token
|
|
890
|
-
# KNAPSACK_PRO_TEST_SUITE_TOKEN_TEST_UNIT: test-unit-token
|
|
891
|
-
# KNAPSACK_PRO_TEST_SUITE_TOKEN_SPINACH: spinach-token
|
|
892
|
-
test:
|
|
893
|
-
override:
|
|
894
|
-
# Step for RSpec
|
|
895
|
-
- bundle exec rake knapsack_pro:rspec:
|
|
896
|
-
parallel: true # Caution: there are 8 spaces indentation!
|
|
897
|
-
|
|
898
|
-
# Step for Cucumber
|
|
899
|
-
- bundle exec rake knapsack_pro:cucumber:
|
|
900
|
-
parallel: true # Caution: there are 8 spaces indentation!
|
|
901
|
-
|
|
902
|
-
# Step for Minitest
|
|
903
|
-
- bundle exec rake knapsack_pro:minitest:
|
|
904
|
-
parallel: true # Caution: there are 8 spaces indentation!
|
|
905
|
-
|
|
906
|
-
# Step for test-unit
|
|
907
|
-
- bundle exec rake knapsack_pro:test_unit:
|
|
908
|
-
parallel: true # Caution: there are 8 spaces indentation!
|
|
909
|
-
|
|
910
|
-
# Step for Spinach
|
|
911
|
-
- bundle exec rake knapsack_pro:spinach:
|
|
912
|
-
parallel: true # Caution: there are 8 spaces indentation!
|
|
913
|
-
```
|
|
914
|
-
|
|
915
|
-
Here is another example for CircleCI 2.0 platform.
|
|
796
|
+
Here is an example for test configuration in your `.circleci/config.yml` file.
|
|
916
797
|
|
|
917
798
|
```yaml
|
|
918
799
|
# CircleCI 2.0
|
|
@@ -949,9 +830,9 @@ Please remember to add additional containers for your project in CircleCI settin
|
|
|
949
830
|
|
|
950
831
|
##### CircleCI and knapsack_pro Queue Mode
|
|
951
832
|
|
|
952
|
-
If you use knapsack_pro Queue Mode with CircleCI you may want to [collect metadata](https://circleci.com/docs/
|
|
833
|
+
If you use knapsack_pro Queue Mode with CircleCI you may want to [collect metadata](https://circleci.com/docs/2.0/collect-test-data/#metadata-collection-in-custom-test-steps) like junit xml report about your RSpec test suite.
|
|
953
834
|
|
|
954
|
-
Here you can read how to configure [junit formatter](#how-to-use-junit-formatter-with-knapsack_pro-queue-mode). Step for CircleCI is to copy the xml report to `$CIRCLE_TEST_REPORTS` directory. Below is full config for your `spec_helper.rb`:
|
|
835
|
+
Here you can read how to configure [junit formatter](https://knapsackpro.com/faq/question/how-to-use-junit-formatter#how-to-use-junit-formatter-with-knapsack_pro-queue-mode). Step for CircleCI is to copy the xml report to `$CIRCLE_TEST_REPORTS` directory. Below is full config for your `spec_helper.rb`:
|
|
955
836
|
|
|
956
837
|
```ruby
|
|
957
838
|
# spec_helper.rb or rails_helper.rb
|
|
@@ -996,6 +877,8 @@ Ensure you have in CircleCI config yml
|
|
|
996
877
|
destination: test-results
|
|
997
878
|
```
|
|
998
879
|
|
|
880
|
+
You can find a complete CircleCI YML config example in [the article](https://docs.knapsackpro.com/2021/rspec-testing-parallel-jobs-with-circleci-and-junit-xml-report).
|
|
881
|
+
|
|
999
882
|
#### Info for Travis users
|
|
1000
883
|
|
|
1001
884
|
You can parallelize your builds across virtual machines with [travis matrix feature](http://docs.travis-ci.com/user/speeding-up-the-build/#parallelizing-your-builds-across-virtual-machines). Edit `.travis.yml`
|
|
@@ -1560,7 +1443,7 @@ Remember to set environment variables in Jenkins configuration with your API tok
|
|
|
1560
1443
|
Here is [list of environment variables per test runner](#set-api-key-token).
|
|
1561
1444
|
|
|
1562
1445
|
Above example shows how to run cucumber tests in regular mode and later the rspec tests in queue mode to autobalance build.
|
|
1563
|
-
If you are going to relay on rspec to autobalance build when cucumber tests were not perfectly distributed you should be aware about [possible edge case if your rspec test suite is very short](
|
|
1446
|
+
If you are going to relay on rspec to autobalance build when cucumber tests were not perfectly distributed you should be aware about [possible edge case if your rspec test suite is very short](https://knapsackpro.com/faq/question/why-my-tests-are-executed-twice-in-queue-mode-why-ci-node-runs-whole-test-suite-again).
|
|
1564
1447
|
|
|
1565
1448
|
#### Info for GitHub Actions users
|
|
1566
1449
|
|
|
@@ -1600,12 +1483,12 @@ jobs:
|
|
|
1600
1483
|
strategy:
|
|
1601
1484
|
fail-fast: false
|
|
1602
1485
|
matrix:
|
|
1603
|
-
#
|
|
1604
|
-
# Use higher number if you have slow tests to split them
|
|
1605
|
-
# Remember to update ci_node_index below to 0..
|
|
1486
|
+
# [n] - where the n is a number of parallel jobs you want to run your tests on.
|
|
1487
|
+
# Use a higher number if you have slow tests to split them between more parallel jobs.
|
|
1488
|
+
# Remember to update the value of the `ci_node_index` below to (0..n-1).
|
|
1606
1489
|
ci_node_total: [2]
|
|
1607
|
-
#
|
|
1608
|
-
#
|
|
1490
|
+
# Indexes for parallel jobs (starting from zero).
|
|
1491
|
+
# E.g. use [0, 1] for 2 parallel jobs, [0, 1, 2] for 3 parallel jobs, etc.
|
|
1609
1492
|
ci_node_index: [0, 1]
|
|
1610
1493
|
|
|
1611
1494
|
steps:
|
|
@@ -1789,1454 +1672,6 @@ WORKDIR /src
|
|
|
1789
1672
|
RUN bundle install
|
|
1790
1673
|
```
|
|
1791
1674
|
|
|
1792
|
-
## FAQ
|
|
1793
|
-
|
|
1794
|
-
### Common problems
|
|
1795
|
-
|
|
1796
|
-
#### Why I see API error commit_hash parameter is required?
|
|
1797
|
-
|
|
1798
|
-
ERROR -- : [knapsack_pro] {"errors"=>[{"commit_hash"=>["parameter is required"]}]}
|
|
1799
|
-
|
|
1800
|
-
When Knapsack Pro API returns error like above the problem is because you use CI provider not supported by knapsack_pro which means
|
|
1801
|
-
knapsack_pro gem cannot determine the git commit hash and branch name. To fix this problem you can do:
|
|
1802
|
-
|
|
1803
|
-
* if you have git installed on CI node then you can use it to determine git commit hash and branch name. [See this](#when-should-you-set-global-variable-knapsack_pro_repository_adaptergit-required-when-ci-provider-is-not-supported)
|
|
1804
|
-
* if you have no git installed on CI node then you should manually set `KNAPSACK_PRO_BRANCH` and `KNAPSACK_PRO_COMMIT_HASH`. For instance this might be useful when you use Jenkins. [See this](#when-you-not-set-global-variable-knapsack_pro_repository_adapter-default)
|
|
1805
|
-
|
|
1806
|
-
#### Why I see `LoadError: cannot load such file -- spec_helper`?
|
|
1807
|
-
|
|
1808
|
-
When your tests fails with:
|
|
1809
|
-
|
|
1810
|
-
LoadError: cannot load such file -- spec_helper
|
|
1811
|
-
|
|
1812
|
-
then problem might be related to the fact you specified complex `KNAPSACK_PRO_TEST_FILE_PATTERN` and knapsack_pro gem cannot detect correct main test directory with spec_helper. You should set `KNAPSACK_PRO_TEST_DIR=spec`. Please [read also example](#how-can-i-run-tests-from-multiple-directories).
|
|
1813
|
-
|
|
1814
|
-
#### Why my CI build fails when I use Test::Unit even when all tests passed?
|
|
1815
|
-
|
|
1816
|
-
Please ensure you are actually using only Test::Unit runner. You may use some hybrid of Test::Unit and Minitest. Ensure you are not loading Minitest.
|
|
1817
|
-
|
|
1818
|
-
#### Why I see HEAD as branch name in user dashboard for Build metrics for my API token?
|
|
1819
|
-
|
|
1820
|
-
knapsack_pro detects your branch name from environment variables of [supported CI providers](#supported-ci-providers). Sometimes the CI provider may expose the `HEAD` instead of branch name (for instance for pull request merge commits).
|
|
1821
|
-
|
|
1822
|
-
The same can happen for CI provider not supported by default by knapsack_pro when you use [KNAPSACK_PRO_REPOSITORY_ADAPTER=git](#when-should-you-set-global-variable-knapsack_pro_repository_adaptergit-required-when-ci-provider-is-not-supported) to use local git installed on CI node to detect the branch name and git commit.
|
|
1823
|
-
|
|
1824
|
-
knapsack_pro uses git command `git -C /home/user/project_dir rev-parse --abbrev-ref HEAD` to detect branch name. See [source of knapsack_pro](https://github.com/KnapsackPro/knapsack_pro-ruby/blob/master/lib/knapsack_pro/repository_adapters/git_adapter.rb). In most of cases it's good way to detect branch name. But if your CI provider during CI build checkouts to specific git commit then git cannot provide the name of the branch. In such scenario you would see `HEAD` as your branch name. It is good enough situation and knapsack_pro will work correctly. The benefit of knowing exactly the branch name allows KnapsackPro API to better track history of test files timing changes across branches in order to better do split of test suite. The difference should be rather very small so it's not a problem that you have `HEAD` as branch name.
|
|
1825
|
-
|
|
1826
|
-
If you would like to see exact branch name instead of `HEAD` in your `build metrics` history in [user dashboard](https://knapsackpro.com/dashboard) then you can explicitly provide the branch name with `KNAPSACK_PRO_BRANCH` for each CI build.
|
|
1827
|
-
|
|
1828
|
-
#### Why Capybara feature tests randomly fail when using CI parallelisation?
|
|
1829
|
-
|
|
1830
|
-
It can happen that when you use CI parallelisation then your CI machine is overloaded and some of Capybara feature specs may randomly fail when tested website loaded slowly.
|
|
1831
|
-
|
|
1832
|
-
You can try to increase default Capybara max wait time from 2 seconds to something bigger like 5 seconds to ensure the Capybara will wait longer till the website is loaded before marking test as failed.
|
|
1833
|
-
|
|
1834
|
-
```ruby
|
|
1835
|
-
# spec/rails_helper.rb
|
|
1836
|
-
Capybara.default_max_wait_time = 5 # in seconds
|
|
1837
|
-
```
|
|
1838
|
-
|
|
1839
|
-
For instance, this tip might be helpful for Heroku CI users who use Heroku dynos with lower performance.
|
|
1840
|
-
|
|
1841
|
-
#### Why knapsack_pro freezes / hangs my CI (for instance Travis)?
|
|
1842
|
-
|
|
1843
|
-
[Freeze error can occur for example on Travis CI](https://docs.travis-ci.com/user/common-build-problems/#ruby-tests-frozen-and-cancelled-after-10-minute-log-silence).
|
|
1844
|
-
The `timecop` gem can result in sporadic freezing due to issues with ordering calls of `Timecop.return`, `Timecop.freeze`, and `Timecop.travel`. For instance, if using RSpec, ensure to have a `Timecop.return` configured to run after all examples:
|
|
1845
|
-
|
|
1846
|
-
```ruby
|
|
1847
|
-
# in, e.g. spec/spec_helper.rb
|
|
1848
|
-
RSpec.configure do |c|
|
|
1849
|
-
c.after(:all) do
|
|
1850
|
-
Timecop.return
|
|
1851
|
-
end
|
|
1852
|
-
end
|
|
1853
|
-
```
|
|
1854
|
-
|
|
1855
|
-
#### Why tests hitting external API fail?
|
|
1856
|
-
|
|
1857
|
-
If you use knapsack_pro and you have tests that do real HTTP requests to external API you need to ensure your tests can be run across parallel CI nodes.
|
|
1858
|
-
|
|
1859
|
-
Let's say you have tests that do requests to Stripe API or any other API. Before running each test you want to make sure Stripe Sandbox is clean up so you have removed all fake subscriptions and customers from Stripe Sandbox.
|
|
1860
|
-
|
|
1861
|
-
```ruby
|
|
1862
|
-
# RSpec hook
|
|
1863
|
-
before(:each) do
|
|
1864
|
-
Stripe::Subscription.all.each { |sub| sub.delete }
|
|
1865
|
-
Stripe::Customer.all.each { |customer| customer.delete }
|
|
1866
|
-
end
|
|
1867
|
-
```
|
|
1868
|
-
|
|
1869
|
-
But this will cause a problem when 2 different test files will run on 2 different CI nodes at the same time and this hook will be called. You will remove subscriptions and customers while another parallel test was running. Simply speaking you have tests that are written in a way that you can't run them in parallel.
|
|
1870
|
-
|
|
1871
|
-
To fix that you can think of:
|
|
1872
|
-
* using [VCR](https://github.com/vcr/vcr) gem to record HTTP requests and then instead of doing real HTTP requests just reply recorded requests.
|
|
1873
|
-
* maybe you could write your tests in a way when you generate some fake customers or subscriptions with fake id and each test has different customer id so there will be no conflict when 2 tests are run at the same time.
|
|
1874
|
-
|
|
1875
|
-
#### Why green test suite for Cucumber 2.99 tests always fails with `invalid option: --require`?
|
|
1876
|
-
|
|
1877
|
-
If you use old Cucumber version 2.99 and `cucumber-rails` gem you could notice bug that knapsack_pro for Cucumber fails with `1` exit status. Error you may see:
|
|
1878
|
-
|
|
1879
|
-
```
|
|
1880
|
-
invalid option: --require
|
|
1881
|
-
|
|
1882
|
-
minitest options:
|
|
1883
|
-
-h, --help Display this help.
|
|
1884
|
-
--no-plugins Bypass minitest plugin auto-loading (or set $MT_NO_PLUGINS).
|
|
1885
|
-
-s, --seed SEED Sets random seed. Also via env. Eg: SEED=n rake
|
|
1886
|
-
-v, --verbose Verbose. Show progress processing files.
|
|
1887
|
-
-n, --name PATTERN Filter run on /regexp/ or string.
|
|
1888
|
-
--exclude PATTERN Exclude /regexp/ or string from run.
|
|
1889
|
-
|
|
1890
|
-
Known extensions: rails, pride
|
|
1891
|
-
-w, --warnings Run with Ruby warnings enabled
|
|
1892
|
-
-e, --environment ENV Run tests in the ENV environment
|
|
1893
|
-
-b, --backtrace Show the complete backtrace
|
|
1894
|
-
-d, --defer-output Output test failures and errors after the test run
|
|
1895
|
-
-f, --fail-fast Abort test run on first failure or error
|
|
1896
|
-
-c, --[no-]color Enable color in the output
|
|
1897
|
-
-p, --pride Pride. Show your testing pride!
|
|
1898
|
-
|
|
1899
|
-
# exit status is 1 - which means failed tests
|
|
1900
|
-
> echo $?
|
|
1901
|
-
1
|
|
1902
|
-
```
|
|
1903
|
-
|
|
1904
|
-
The root problem is that Rails add `minitest` gem and it is started when `cucumber/rails` is loaded. It should not be. You can fix it by adding below in file `features/support/env.rb`:
|
|
1905
|
-
|
|
1906
|
-
```ruby
|
|
1907
|
-
# features/support/env.rb
|
|
1908
|
-
require 'cucumber/rails'
|
|
1909
|
-
|
|
1910
|
-
# this must be after we require cucumber/rails
|
|
1911
|
-
require 'multi_test'
|
|
1912
|
-
MultiTest.disable_autorun
|
|
1913
|
-
```
|
|
1914
|
-
|
|
1915
|
-
The solution comes from: [cucumber/multi_test](https://github.com/cucumber/multi_test/pull/2#issuecomment-21863459)
|
|
1916
|
-
|
|
1917
|
-
#### Queue Mode problems
|
|
1918
|
-
|
|
1919
|
-
##### Why when I use Queue Mode for RSpec then my tests fail?
|
|
1920
|
-
|
|
1921
|
-
knapsack_pro Queue Mode uses `RSpec::Core::Runner` feature that allows [running specs multiple times with different runner options in the same process](https://relishapp.com/rspec/rspec-core/docs/running-specs-multiple-times-with-different-runner-options-in-the-same-process).
|
|
1922
|
-
Thanks to that we can run subset of test suite pulled from Knapsack Pro API work queue. This allows dynamic allocation of your tests across CI nodes without reloading whole Ruby/Rails application for each run of test suite subset.
|
|
1923
|
-
|
|
1924
|
-
If you have custom things that are not common in how typical RSpec spec looks like then the RSpec feature won't be able to handle it between test suite subset runs.
|
|
1925
|
-
In that case you need to resolve failed tests in a way that allows RSpec to run the tests. Feel free to [ask me for help](https://knapsackpro.com/contact).
|
|
1926
|
-
|
|
1927
|
-
You can learn more about [recent RSpec team changes](https://github.com/KnapsackPro/knapsack_pro-ruby/pull/42) that was backported into knapsack_pro.
|
|
1928
|
-
|
|
1929
|
-
To solve failing tests in Queue Mode you can check:
|
|
1930
|
-
|
|
1931
|
-
* you use full namespacing. If you see error like `NameError: uninitialized constant MyModule::ModelName` then in some cases a top-level constant would be matched if the code hadn't been loaded for the scoped constant. Try to use full namespacing `::SomeModule::MyModule::ModelName` etc.
|
|
1932
|
-
* you can try to use binary version of knapsack_pro instead of running it via rake task. This helps if your rake tasks mess up with tests and make knapsack_pro Queue Mode fail. [See example](#why-when-i-use-queue-mode-for-rspec-then-factorybotfactorygirl-tests-fail):
|
|
1933
|
-
|
|
1934
|
-
```bash
|
|
1935
|
-
# Knapsack Pro Queue Mode run via binary
|
|
1936
|
-
bundle exec knapsack_pro queue:rspec "--profile 10 --format progress"
|
|
1937
|
-
```
|
|
1938
|
-
|
|
1939
|
-
* You can check below questions for common reasons of failing tests in Queue Mode
|
|
1940
|
-
|
|
1941
|
-
##### Why when I use Queue Mode for RSpec then FactoryBot/FactoryGirl tests fail?
|
|
1942
|
-
|
|
1943
|
-
You can use [knapsack_pro binary](#knapsack-pro-binary) instead of rake task version to solve problem:
|
|
1944
|
-
|
|
1945
|
-
```bash
|
|
1946
|
-
# knapsack_pro binary for Queue Mode
|
|
1947
|
-
$ bundle exec knapsack_pro queue:rspec
|
|
1948
|
-
```
|
|
1949
|
-
|
|
1950
|
-
Other solution is to check if your factories for FactoryBot/FactoryGirl use the same methods as Rake DSL and remove problematic part of the code.
|
|
1951
|
-
|
|
1952
|
-
The use of implicit association `task` can cause a problem.
|
|
1953
|
-
|
|
1954
|
-
```ruby
|
|
1955
|
-
# won't work in knapsack_pro Queue Mode
|
|
1956
|
-
FactoryBot.define do
|
|
1957
|
-
factory :assignment do
|
|
1958
|
-
task
|
|
1959
|
-
end
|
|
1960
|
-
end
|
|
1961
|
-
```
|
|
1962
|
-
|
|
1963
|
-
Workaround is to replace `task` with explicit association:
|
|
1964
|
-
|
|
1965
|
-
```ruby
|
|
1966
|
-
# this will work in knapsack_pro Queue Mode
|
|
1967
|
-
FactoryBot.define do
|
|
1968
|
-
factory :assignment do
|
|
1969
|
-
association :task
|
|
1970
|
-
end
|
|
1971
|
-
end
|
|
1972
|
-
```
|
|
1973
|
-
|
|
1974
|
-
##### Why when I use Queue Mode for RSpec then my rake tasks are run twice?
|
|
1975
|
-
|
|
1976
|
-
Why rake tasks are being ran twice in Queue Mode? If you have tests for your rake task then you want to ensure you clear the rake task before loading it inside of test file.
|
|
1977
|
-
In Queue Mode the rake task could be already loaded and loading it again in test file may result in running the task twice.
|
|
1978
|
-
|
|
1979
|
-
```ruby
|
|
1980
|
-
before do
|
|
1981
|
-
# Clear rake task from memory if it was already loaded.
|
|
1982
|
-
# This ensures rake task is loaded only once in knapsack_pro Queue Mode.
|
|
1983
|
-
Rake::Task[task_name].clear if Rake::Task.task_defined?(task_name)
|
|
1984
|
-
|
|
1985
|
-
# loaad rake task only once here
|
|
1986
|
-
Rake.application.rake_require("tasks/dummy")
|
|
1987
|
-
Rake::Task.define_task(:environment)
|
|
1988
|
-
end
|
|
1989
|
-
```
|
|
1990
|
-
|
|
1991
|
-
Here is the full [example how to test rake task along with dummy rake task](https://github.com/KnapsackPro/rails-app-with-knapsack_pro/commit/9f068e900deb3554bd72633e8d61c1cc7f740306) from our example rails project.
|
|
1992
|
-
|
|
1993
|
-
##### Why when I use Queue Mode for RSpec then I see error `superclass mismatch for class`?
|
|
1994
|
-
|
|
1995
|
-
You may see error like:
|
|
1996
|
-
|
|
1997
|
-
```
|
|
1998
|
-
TypeError:
|
|
1999
|
-
superclass mismatch for class BatchClass
|
|
2000
|
-
```
|
|
2001
|
-
|
|
2002
|
-
when you have 2 test files like this one:
|
|
2003
|
-
|
|
2004
|
-
```ruby
|
|
2005
|
-
# spec/a_spec.rb
|
|
2006
|
-
class BaseBatchClass
|
|
2007
|
-
end
|
|
2008
|
-
|
|
2009
|
-
module Mock
|
|
2010
|
-
module FakeModels
|
|
2011
|
-
class BatchClass < BaseBatchClass
|
|
2012
|
-
def args
|
|
2013
|
-
end
|
|
2014
|
-
end
|
|
2015
|
-
end
|
|
2016
|
-
end
|
|
2017
|
-
|
|
2018
|
-
describe 'A test of something' do
|
|
2019
|
-
it do
|
|
2020
|
-
end
|
|
2021
|
-
end
|
|
2022
|
-
```
|
|
2023
|
-
|
|
2024
|
-
```ruby
|
|
2025
|
-
# spec/b_spec.rb
|
|
2026
|
-
class DifferentBaseBatchClass
|
|
2027
|
-
end
|
|
2028
|
-
|
|
2029
|
-
module Mock
|
|
2030
|
-
module FakeModels
|
|
2031
|
-
# Note the base class is different here!
|
|
2032
|
-
class BatchClass < DifferentBaseBatchClass
|
|
2033
|
-
def args
|
|
2034
|
-
end
|
|
2035
|
-
end
|
|
2036
|
-
end
|
|
2037
|
-
end
|
|
2038
|
-
|
|
2039
|
-
describe 'B test of something' do
|
|
2040
|
-
it do
|
|
2041
|
-
end
|
|
2042
|
-
end
|
|
2043
|
-
```
|
|
2044
|
-
|
|
2045
|
-
Instead of mocking like shown above you could use [RSpec stub_const](https://relishapp.com/rspec/rspec-mocks/docs/mutating-constants) to solve error `superclass mismatch for class BatchClass`.
|
|
2046
|
-
|
|
2047
|
-
##### Why when I use Queue Mode for RSpec then `.rspec` config is ignored?
|
|
2048
|
-
|
|
2049
|
-
The `.rspec` config file is ignored in Queue Mode because knapsack_pro has to pass explicitly arguments to `RSpec::Core::Runner` underhood. You can set your arguments from `.rspec` file in an inline way.
|
|
2050
|
-
|
|
2051
|
-
```
|
|
2052
|
-
bundle exec rake "knapsack_pro:queue:rspec[--format documentation --require rails_helper]"
|
|
2053
|
-
```
|
|
2054
|
-
|
|
2055
|
-
See [passing arguments to RSpec](#passing-arguments-to-rspec).
|
|
2056
|
-
|
|
2057
|
-
##### Why I don't see collected time execution data for my build in user dashboard?
|
|
2058
|
-
|
|
2059
|
-
If you go to [user dashboard](https://knapsackpro.com/dashboard) and open `Build metrics` for your API token and you open build for your last git commit you should see there info about collected time execution data from all CI nodes. If you don't see collected time execution data for CI nodes then please ensure:
|
|
2060
|
-
|
|
2061
|
-
* you have `Knapsack::Adapters::RspecAdapter.bind` in your `rails_helper.rb` or `spec_helper.rb`
|
|
2062
|
-
* you explicitly set `RAILS_ENV=test` on your CI nodes (for instance you use Docker then please set `RAILS_ENV`)
|
|
2063
|
-
* knapsack_pro Queue Mode saves temporary files with collected time execution data in `your_rails_project/tmp/knapsack_pro/queue/`. Please ensure you don't clean `tmp` directory in your tests so knapsack_pro can publish time execution data to Knapsack Pro API server.
|
|
2064
|
-
|
|
2065
|
-
##### Why all test files have 0.1s time execution for my CI build in user dashboard?
|
|
2066
|
-
|
|
2067
|
-
If you go to [user dashboard](https://knapsackpro.com/dashboard) and open `Build metrics` for your API token and you open CI build for your last git commit you should see there info about collected time execution data from all CI nodes. If you see all test files have 0.1s time execution then please ensure:
|
|
2068
|
-
|
|
2069
|
-
* you should not clean up `tmp` directory in your tests (for instance in RSpec hooks like `before` or `after`) so knapsack_pro can publish measured time execution data to Knapsack Pro API server. knapsack_pro Queue Mode saves temporary files with collected time execution data in `your_rails_project/tmp/knapsack_pro/queue/`.
|
|
2070
|
-
* please ensure you have in your `rails_helper.rb` or `spec_helper.rb` line that allows to measure tests:
|
|
2071
|
-
|
|
2072
|
-
```ruby
|
|
2073
|
-
require 'knapsack_pro'
|
|
2074
|
-
|
|
2075
|
-
# CUSTOM_CONFIG_GOES_HERE
|
|
2076
|
-
|
|
2077
|
-
KnapsackPro::Adapters::RSpecAdapter.bind
|
|
2078
|
-
```
|
|
2079
|
-
|
|
2080
|
-
The 0.1s is a default time execution used when test file is an empty file or its content are all pending tests.
|
|
2081
|
-
|
|
2082
|
-
##### Why when I use Queue Mode for RSpec and test fails then I see multiple times info about failed test in RSpec result?
|
|
2083
|
-
|
|
2084
|
-
The problem may happen when you use old knapsack_pro `< 0.33.0` or if you use custom rspec formatter, or when you set flag [KNAPSACK_PRO_MODIFY_DEFAULT_RSPEC_FORMATTERS=false](#knapsack_pro_modify_default_rspec_formatters-hide-duplicated-summary-of-pending-and-failed-tests).
|
|
2085
|
-
|
|
2086
|
-
When you use Queue Mode then knapsack_pro does multiple requests to Knapsack Pro API and fetches a few test files to execute.
|
|
2087
|
-
This means RSpec will remember failed tests so far and it will present them at the end of each executed test subset if flag `KNAPSACK_PRO_MODIFY_DEFAULT_RSPEC_FORMATTERS=false`.
|
|
2088
|
-
You can see the list of all failed test files at the end of knapsack_pro queue mode command.
|
|
2089
|
-
|
|
2090
|
-
##### Why when I use Queue Mode for RSpec then I see multiple times the same pending tests?
|
|
2091
|
-
|
|
2092
|
-
The problem may happen when you use old knapsack_pro `< 0.33.0` or if you use custom rspec formatter, or when you set flag [KNAPSACK_PRO_MODIFY_DEFAULT_RSPEC_FORMATTERS=false](#knapsack_pro_modify_default_rspec_formatters-hide-duplicated-summary-of-pending-and-failed-tests).
|
|
2093
|
-
|
|
2094
|
-
When you use Queue Mode then knapsack_pro does multiple requests to Knapsack Pro API and fetches a few test files to execute.
|
|
2095
|
-
This means RSpec will remember pending tests so far and it will present them at the end of each executed test subset if flag `KNAPSACK_PRO_MODIFY_DEFAULT_RSPEC_FORMATTERS=false`.
|
|
2096
|
-
You can see the list of all pending test files at the end of knapsack_pro queue mode command.
|
|
2097
|
-
|
|
2098
|
-
##### Does in Queue Mode the RSpec is initialized many times that causes Rails load over and over again?
|
|
2099
|
-
|
|
2100
|
-
No. In Queue Mode the RSpec configuration is updated every time when knapsack_pro gem gets a new set of test files from the Knapsack Pro API and it looks in knapsack_pro output like RSpec was loaded many times but in fact, it loads your project environment only once.
|
|
2101
|
-
|
|
2102
|
-
##### Why my tests are executed twice in queue mode? Why CI node runs whole test suite again?
|
|
2103
|
-
|
|
2104
|
-
This may happen when you use not supported CI provider by knapsack_pro. It's because of missing value of CI build ID. You can set unique `KNAPSACK_PRO_CI_NODE_BUILD_ID` for each CI build. The problem with test suite run again happens when one of your CI node started work later when all other CI nodes already executed whole test suite.
|
|
2105
|
-
The slow CI node that started work late will initialize a new queue hence the tests executed twice.
|
|
2106
|
-
|
|
2107
|
-
To solve this problem you can set `KNAPSACK_PRO_CI_NODE_BUILD_ID` as mentioned above or you can set `KNAPSACK_PRO_FIXED_QUEUE_SPLIT=true`.
|
|
2108
|
-
Please [read this](#knapsack_pro_fixed_queue_split-remember-queue-split-on-retry-ci-node).
|
|
2109
|
-
|
|
2110
|
-
##### How to fix capybara-screenshot fail with `SystemStackError: stack level too deep` when using Queue Mode for RSpec?
|
|
2111
|
-
|
|
2112
|
-
Please use fixed version of capybara-screenshot.
|
|
2113
|
-
|
|
2114
|
-
```ruby
|
|
2115
|
-
# Gemfile
|
|
2116
|
-
group :test do
|
|
2117
|
-
gem 'capybara-screenshot', github: 'mattheworiordan/capybara-screenshot', branch: 'master'
|
|
2118
|
-
end
|
|
2119
|
-
```
|
|
2120
|
-
|
|
2121
|
-
Here is [fix PR](https://github.com/mattheworiordan/capybara-screenshot/pull/205) to official capybara-screenshot repository and the explanation of the problem.
|
|
2122
|
-
|
|
2123
|
-
##### Parallel tests Cucumber and RSpec with Cucumber failures exit CI node early leaving fewer CI nodes to finish RSpec Queue.
|
|
2124
|
-
|
|
2125
|
-
If you run tests in 2 steps like:
|
|
2126
|
-
|
|
2127
|
-
* Step 1. `bundle exec rake knapsack_pro:cucumber` (regular mode)
|
|
2128
|
-
* Step 2. `bundle exec rake knapsack_pro:queue:rspec` (queue mode)
|
|
2129
|
-
|
|
2130
|
-
and your CI provider is configured to fail fast when one of the steps fails then in the case when the first step with Cucumber fails on one of CI nodes then the second step with RSpec in Queue Mode won't start on the CI node that failed fast.
|
|
2131
|
-
|
|
2132
|
-
It means the other CI nodes that will run the second step for RSpec in Queue Mode will consume the whole RSpec Queue so your whole CI build will take more than typical CI build when all Cucumber tests are green.
|
|
2133
|
-
|
|
2134
|
-
You should configure your CI provider to not fail fast the Cucumber step.
|
|
2135
|
-
|
|
2136
|
-
CI providers tips:
|
|
2137
|
-
|
|
2138
|
-
* If you use CircleCI 2.0 you can use `when=always` flag. Read more [here](https://discuss.circleci.com/t/parallel-tests-cuc-rspec-w-failures-exit-early-leaving-less-workers-to-finish/18081).
|
|
2139
|
-
|
|
2140
|
-
##### Why when I reran the same build (same commit hash, etc) on Codeship then no tests would get executed in Queue Mode?
|
|
2141
|
-
|
|
2142
|
-
Codeship uses the same build ID ([`CI_BUILD_NUMBER`](https://documentation.codeship.com/basic/builds-and-configuration/set-environment-variables/#default-environment-variables)) if you re-run a build, so Codeship is not giving enough information to knapsack_pro gem that this is an independent build. Knapsack Pro API assumes you already ran tests for that build ID hence no tests were executed for reran CI build.
|
|
2143
|
-
|
|
2144
|
-
To fix problem you can set `KNAPSACK_PRO_CI_NODE_BUILD_ID=missing-build-id` as empty string.
|
|
2145
|
-
This way knapsack_pro won’t use build ID provided by Codeship and each build will be treated as a unique. This should be good enough solution for most users.
|
|
2146
|
-
|
|
2147
|
-
There is one edge case with that solution. Please note that the knapsack_pro gem doesn't have a CI build ID in order to generate a queue for each particular CI build. This may result in two different CI builds taking tests from the same queue when CI builds are running at the same time against the same git commit.
|
|
2148
|
-
|
|
2149
|
-
To avoid this you should specify a unique `KNAPSACK_PRO_CI_NODE_BUILD_ID` environment variable for each CI build. This mean that each CI node that is part of particular CI build should have the same value for `KNAPSACK_PRO_CI_NODE_BUILD_ID`.
|
|
2150
|
-
|
|
2151
|
-
##### Why knapsack_pro hangs / freezes / is stale i.e. for Codeship in Queue Mode?
|
|
2152
|
-
|
|
2153
|
-
Some users with larger projects notice that in Queue Mode knapsack_pro ruby process hangs, for instance for CodeShip CI users.
|
|
2154
|
-
|
|
2155
|
-
It happens due too big RSpec log output in Queue Mode. To produce less logs on output you can change log level to `KNAPSACK_PRO_LOG_LEVEL=warn`.
|
|
2156
|
-
|
|
2157
|
-
Learn more about [log levels](#how-can-i-change-log-level).
|
|
2158
|
-
|
|
2159
|
-
##### How to find seed in RSpec output when I use Queue Mode for RSpec?
|
|
2160
|
-
|
|
2161
|
-
In output for RSpec in knapsack_pro Queue Mode you may see message:
|
|
2162
|
-
|
|
2163
|
-
> INFO -- : [knapsack_pro] To retry in development the subset of tests fetched from API queue please run below command on your machine. If you use --order random then remember to add proper --seed 123 that you will find at the end of rspec command.
|
|
2164
|
-
>
|
|
2165
|
-
> INFO -- : [knapsack_pro] bundle exec rspec --default-path spec "spec/a_spec.rb" "spec/b_spec.rb"
|
|
2166
|
-
|
|
2167
|
-
The seed number is used by RSpec only when you tell it, you need to provide argument `--order random`:
|
|
2168
|
-
|
|
2169
|
-
```bash
|
|
2170
|
-
bundle exec rake "knapsack_pro:queue:rspec[--order random]"
|
|
2171
|
-
```
|
|
2172
|
-
|
|
2173
|
-
then in RSpec output you will see something like:
|
|
2174
|
-
|
|
2175
|
-
```
|
|
2176
|
-
Randomized with seed 11055
|
|
2177
|
-
```
|
|
2178
|
-
|
|
2179
|
-
You can use the seed number to run tests in development:
|
|
2180
|
-
|
|
2181
|
-
```bash
|
|
2182
|
-
bundle exec rspec --seed 11055 --default-path spec "spec/a_spec.rb" "spec/b_spec.rb"
|
|
2183
|
-
```
|
|
2184
|
-
|
|
2185
|
-
If you don't use RSpec argument `--order random` then you don't need to provide `--seed` number when you want to reproduce tests in development.
|
|
2186
|
-
|
|
2187
|
-
##### How to configure puffing-billy gem with Knapsack Pro Queue Mode?
|
|
2188
|
-
|
|
2189
|
-
If you use [puffing-billy](https://github.com/oesmith/puffing-billy) gem you may notice [puffing-billy may crash](https://github.com/oesmith/puffing-billy/issues/253). It happen due to the way how knapsack_pro in Queue Mode uses `RSpec::Core::Runner` ([see](#why-when-i-use-queue-mode-for-rspec-then-my-tests-fail)).
|
|
2190
|
-
|
|
2191
|
-
Here is a patch for puffing-billy to make it work in knapsack_pro Queue Mode:
|
|
2192
|
-
|
|
2193
|
-
```ruby
|
|
2194
|
-
# rails_helper.rb or spec_helper.rb
|
|
2195
|
-
|
|
2196
|
-
# A patch to `puffing-billy`'s proxy so that it doesn't try to stop
|
|
2197
|
-
# eventmachine's reactor if it's not running.
|
|
2198
|
-
module BillyProxyPatch
|
|
2199
|
-
def stop
|
|
2200
|
-
return unless EM.reactor_running?
|
|
2201
|
-
super
|
|
2202
|
-
end
|
|
2203
|
-
end
|
|
2204
|
-
Billy::Proxy.prepend(BillyProxyPatch)
|
|
2205
|
-
|
|
2206
|
-
# A patch to `puffing-billy` to start EM if it has been stopped
|
|
2207
|
-
Billy.module_eval do
|
|
2208
|
-
def self.proxy
|
|
2209
|
-
if @billy_proxy.nil? || !(EventMachine.reactor_running? && EventMachine.reactor_thread.alive?)
|
|
2210
|
-
proxy = Billy::Proxy.new
|
|
2211
|
-
proxy.start
|
|
2212
|
-
@billy_proxy = proxy
|
|
2213
|
-
else
|
|
2214
|
-
@billy_proxy
|
|
2215
|
-
end
|
|
2216
|
-
end
|
|
2217
|
-
end
|
|
2218
|
-
|
|
2219
|
-
if ENV["KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC"]
|
|
2220
|
-
KnapsackPro::Hooks::Queue.before_queue do
|
|
2221
|
-
# executes before Queue Mode starts work
|
|
2222
|
-
Billy.proxy.start
|
|
2223
|
-
end
|
|
2224
|
-
|
|
2225
|
-
KnapsackPro::Hooks::Queue.after_queue do
|
|
2226
|
-
# executes after Queue Mode finishes work
|
|
2227
|
-
Billy.proxy.stop
|
|
2228
|
-
end
|
|
2229
|
-
end
|
|
2230
|
-
```
|
|
2231
|
-
|
|
2232
|
-
### General questions
|
|
2233
|
-
|
|
2234
|
-
#### How to run tests for particular CI node in your development environment
|
|
2235
|
-
|
|
2236
|
-
##### for knapsack_pro regular mode
|
|
2237
|
-
|
|
2238
|
-
In your development environment you can debug tests that were run on the particular CI node.
|
|
2239
|
-
For instance to run subset of tests for the first CI node with specified seed you can do.
|
|
2240
|
-
|
|
2241
|
-
```bash
|
|
2242
|
-
KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC=token \
|
|
2243
|
-
KNAPSACK_PRO_REPOSITORY_ADAPTER=git \
|
|
2244
|
-
KNAPSACK_PRO_PROJECT_DIR=~/projects/rails-app \
|
|
2245
|
-
KNAPSACK_PRO_CI_NODE_TOTAL=2 \
|
|
2246
|
-
KNAPSACK_PRO_CI_NODE_INDEX=0 \
|
|
2247
|
-
bundle exec rake "knapsack_pro:rspec[--seed 123]"
|
|
2248
|
-
```
|
|
2249
|
-
|
|
2250
|
-
Above example is for RSpec. You can use respectively rake task name and token environment variable when you want to run tests for minitest, test_unit, cucumber or spinach.
|
|
2251
|
-
It should work when all CI nodes finished work and sent time execution data to Knapsack Pro API.
|
|
2252
|
-
You can visit [user dashboard](https://knapsackpro.com/dashboard) to preview particular CI build and ensure time execution data were collected from all CI nodes.
|
|
2253
|
-
If at least one CI node has not sent time execution data to the Knapsack Pro API then you should check below solution.
|
|
2254
|
-
|
|
2255
|
-
Check test runner output on particular CI node you would like to retry in development. You should see at the beginning of rspec command an output that can
|
|
2256
|
-
be copied and executed in development.
|
|
2257
|
-
|
|
2258
|
-
```
|
|
2259
|
-
/Users/ubuntu/.rvm/gems/ruby-2.4.0/gems/rspec-core-3.4.4/exe/rspec spec/foo_spec.rb spec/bar_spec.rb --default-path spec
|
|
2260
|
-
```
|
|
2261
|
-
|
|
2262
|
-
Command similar to above can be executed in your development this way:
|
|
2263
|
-
|
|
2264
|
-
```bash
|
|
2265
|
-
bundle exec rspec spec/foo_spec.rb spec/bar_spec.rb --default-path spec
|
|
2266
|
-
```
|
|
2267
|
-
|
|
2268
|
-
If you were running your tests with `--order random` on your CI then you can additionaly pass seed param with proper value in above command (`--seed 123`).
|
|
2269
|
-
|
|
2270
|
-
##### for knapsack_pro queue mode
|
|
2271
|
-
|
|
2272
|
-
There are a few ways to reproduce tests executed on CI node in your development environment.
|
|
2273
|
-
|
|
2274
|
-
* At the end of `knapsack_pro:queue:rspec` results you will find example of command that you can copy and paste to your development machine. It will run all tests executed on the CI node in a single run. I recommend this approach.
|
|
2275
|
-
|
|
2276
|
-
* For each intermediate request to Knapsack Pro API queue you will also find example of command to run a subset of tests fetched from API. This might be helpful when you use `--order random` for rspec and you would like to reproduce the tests with the same seed.
|
|
2277
|
-
|
|
2278
|
-
* You can also retry tests and record the time execution data for them again for the particular CI node. Note you must be checkout on the same branch and git commit as your CI node was.
|
|
2279
|
-
|
|
2280
|
-
To retry the particular CI node do this on your machine:
|
|
2281
|
-
|
|
2282
|
-
```bash
|
|
2283
|
-
RACK_ENV=test \
|
|
2284
|
-
RAILS_ENV=test \
|
|
2285
|
-
KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC=token \
|
|
2286
|
-
KNAPSACK_PRO_REPOSITORY_ADAPTER=git \
|
|
2287
|
-
KNAPSACK_PRO_PROJECT_DIR=~/projects/rails-app \
|
|
2288
|
-
KNAPSACK_PRO_CI_NODE_TOTAL=2 \
|
|
2289
|
-
KNAPSACK_PRO_CI_NODE_INDEX=0 \
|
|
2290
|
-
KNAPSACK_PRO_FIXED_QUEUE_SPLIT=true \
|
|
2291
|
-
bundle exec rake "knapsack_pro:queue:rspec"
|
|
2292
|
-
```
|
|
2293
|
-
|
|
2294
|
-
If you were running your tests with `--order random` on your CI like this:
|
|
2295
|
-
|
|
2296
|
-
```bash
|
|
2297
|
-
bundle exec rake "knapsack_pro:queue:rspec[--order random]"
|
|
2298
|
-
```
|
|
2299
|
-
|
|
2300
|
-
Then you can find the seed number visible in rspec output:
|
|
2301
|
-
|
|
2302
|
-
(...)
|
|
2303
|
-
Randomized with seed 123
|
|
2304
|
-
|
|
2305
|
-
You can pass the seed in your local environment to reproduce the tests in the same order as they were executed on CI node:
|
|
2306
|
-
|
|
2307
|
-
```bash
|
|
2308
|
-
RACK_ENV=test \
|
|
2309
|
-
RAILS_ENV=test \
|
|
2310
|
-
KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC=token \
|
|
2311
|
-
KNAPSACK_PRO_REPOSITORY_ADAPTER=git \
|
|
2312
|
-
KNAPSACK_PRO_PROJECT_DIR=~/projects/rails-app \
|
|
2313
|
-
KNAPSACK_PRO_CI_NODE_TOTAL=2 \
|
|
2314
|
-
KNAPSACK_PRO_CI_NODE_INDEX=0 \
|
|
2315
|
-
KNAPSACK_PRO_FIXED_QUEUE_SPLIT=true \
|
|
2316
|
-
bundle exec rake "knapsack_pro:queue:rspec[--seed 123]"
|
|
2317
|
-
```
|
|
2318
|
-
|
|
2319
|
-
#### What happens when Knapsack Pro API is not available/not reachable temporarily?
|
|
2320
|
-
|
|
2321
|
-
##### for knapsack_pro regular mode
|
|
2322
|
-
|
|
2323
|
-
knapsack_pro gem will retry requests to Knapsack Pro API multiple times every few seconds till it switches to fallback behavior (Fallback Mode) and it will split test files across CI nodes based on popular test directory names. When knapsack_pro starts Fallback Mode then you will see a warning in the output.
|
|
2324
|
-
|
|
2325
|
-
Note there is an unlikely scenario when some of the CI nodes may start in Fallback Mode but others don't and then it could happen that some of test files might be skipped. You should [read this to learn more](https://github.com/KnapsackPro/knapsack_pro-ruby/pull/124) and decide if you like to use Fallback Mode when running tests with knapsack_pro Regular Mode.
|
|
2326
|
-
|
|
2327
|
-
If your CI provider allows to retry only one of parallel CI nodes then please [read about this edge case as well](#required-ci-configuration-if-you-use-retry-single-failed-ci-node-feature-on-your-ci-server-when-knapsack_pro_fixed_queue_splittrue-in-queue-mode-or-knapsack_pro_fixed_test_suite_splittrue-in-regular-mode).
|
|
2328
|
-
|
|
2329
|
-
##### for knapsack_pro queue mode
|
|
2330
|
-
|
|
2331
|
-
knapsack_pro gem will retry requests to Knapsack Pro API multiple times every few seconds till it switches to fallback behavior (Fallback Mode) and it will split test files across CI nodes based on popular test directory names.
|
|
2332
|
-
|
|
2333
|
-
Note that if one of the CI nodes loses connection to Knapsack Pro API but others don't, then some of the test files may be executed on multiple CI nodes. **Fallback Mode guarantees each of the test files is run at least once across CI nodes when you use knapsack_pro in Queue Mode.** Thanks to that we know if the whole test suite is green or not. When knapsack_pro starts Fallback Mode then you will see a warning in the output.
|
|
2334
|
-
|
|
2335
|
-
If your CI provider allows to retry only one of parallel CI nodes then please [read about this edge case as well](#required-ci-configuration-if-you-use-retry-single-failed-ci-node-feature-on-your-ci-server-when-knapsack_pro_fixed_queue_splittrue-in-queue-mode-or-knapsack_pro_fixed_test_suite_splittrue-in-regular-mode).
|
|
2336
|
-
|
|
2337
|
-
#### How can I change log level?
|
|
2338
|
-
|
|
2339
|
-
You can change log level by specifying the `KNAPSACK_PRO_LOG_LEVEL` environment variable.
|
|
2340
|
-
|
|
2341
|
-
KNAPSACK_PRO_LOG_LEVEL=info bundle exec rake knapsack_pro:rspec
|
|
2342
|
-
|
|
2343
|
-
Available values are `debug` (default), `info`, `warn`, `error` and `fatal`.
|
|
2344
|
-
|
|
2345
|
-
Recommended log levels you can use:
|
|
2346
|
-
|
|
2347
|
-
* `debug` is default log level and it is recommended to log details about requests to Knapsack Pro API. Thanks to that you can debug things or ensure everything works. For instance in [user dashboard](https://knapsackpro.com/dashboard) you can find tips referring to debug logs.
|
|
2348
|
-
* `info` level shows message like how to retry tests in development or info why something works this way or the other (for instance why tests were not executed on the CI node). You can use `info` level when you really don't want to see all debug messages from default log level.
|
|
2349
|
-
|
|
2350
|
-
#### How to write knapsack_pro logs to a file?
|
|
2351
|
-
|
|
2352
|
-
##### set directory where to write log file (option 1 - recommended)
|
|
2353
|
-
|
|
2354
|
-
Set `KNAPSACK_PRO_LOG_DIR=log` environment variable in order to notify knapsack_pro gem to write logs to `log` directory instead of stdout.
|
|
2355
|
-
If you have Rails project then this should work for you.
|
|
2356
|
-
|
|
2357
|
-
knapsack_pro will create a file with CI node index in name. For instance if you run tests on 2 CI nodes:
|
|
2358
|
-
|
|
2359
|
-
* `log/knapsack_pro_node_0.log`
|
|
2360
|
-
* `log/knapsack_pro_node_1.log`
|
|
2361
|
-
|
|
2362
|
-
`KNAPSACK_PRO_LOG_DIR` has higher priority than custom log set in `rails_helper.rb` as shown below (option 2).
|
|
2363
|
-
|
|
2364
|
-
You can change log level with [KNAPSACK_PRO_LOG_LEVEL environment variable](#how-can-i-change-log-level).
|
|
2365
|
-
|
|
2366
|
-
##### set custom logger config (option 2)
|
|
2367
|
-
|
|
2368
|
-
In your `rails_helper.rb` you can set custom Knapsack Pro logger and write to custom log file.
|
|
2369
|
-
|
|
2370
|
-
```ruby
|
|
2371
|
-
# Ensure you load Rails before using Rails const below.
|
|
2372
|
-
# This line should be already in your rails_helper.rb
|
|
2373
|
-
require File.expand_path('../../config/environment', __FILE__)
|
|
2374
|
-
|
|
2375
|
-
require 'logger'
|
|
2376
|
-
KnapsackPro.logger = Logger.new(Rails.root.join('log', "knapsack_pro_node_#{KnapsackPro::Config::Env.ci_node_index}.log"))
|
|
2377
|
-
KnapsackPro.logger.level = Logger::DEBUG
|
|
2378
|
-
```
|
|
2379
|
-
|
|
2380
|
-
Note if you run knapsack_pro then the very first request to Knapsack Pro API still will be shown to stdout because we need to have set of test files needed to run RSpec before we load `rails_helper.rb` where the configuration of logger actually is loaded for the first time.
|
|
2381
|
-
|
|
2382
|
-
That is why you may prefer to use option 1 instead of this.
|
|
2383
|
-
|
|
2384
|
-
##### How to preserve logs on my CI after CI build completed?
|
|
2385
|
-
|
|
2386
|
-
Follow this tip if you use one of above options to write knapsack_pro log to the file.
|
|
2387
|
-
|
|
2388
|
-
If you would like to keep knapsack_pro logs after your CI build finished then you could use artifacts or some cache mechanize for your CI provider.
|
|
2389
|
-
|
|
2390
|
-
For instance, for [CircleCI 2.0 artifacts](https://circleci.com/docs/2.0/artifacts/) you can specify log directory:
|
|
2391
|
-
|
|
2392
|
-
```yaml
|
|
2393
|
-
- run:
|
|
2394
|
-
name: RSpec via knapsack_pro Queue Mode
|
|
2395
|
-
command: |
|
|
2396
|
-
# export word is important here!
|
|
2397
|
-
export RAILS_ENV=test
|
|
2398
|
-
bundle exec rake "knapsack_pro:queue:rspec[--format documentation]"
|
|
2399
|
-
|
|
2400
|
-
- store_artifacts:
|
|
2401
|
-
path: log
|
|
2402
|
-
```
|
|
2403
|
-
|
|
2404
|
-
Now you can preview logs in `Artifacts` tab in the Circle CI build view.
|
|
2405
|
-
|
|
2406
|
-
#### How to split tests based on test level instead of test file level?
|
|
2407
|
-
|
|
2408
|
-
If you want to split one big test file (test file with long time execution) across multiple CI nodes then you can [check this tip](#split-test-files-by-test-cases) or use other methods like:
|
|
2409
|
-
|
|
2410
|
-
##### A. Create multiple small test files
|
|
2411
|
-
|
|
2412
|
-
Create multiple small test files instead of one long running test file with many test cases.
|
|
2413
|
-
A lot of small test files will give you better test suite split results.
|
|
2414
|
-
|
|
2415
|
-
##### B. Use tags to mark set of tests in particular test file
|
|
2416
|
-
|
|
2417
|
-
Another way is to use tags to mark subset of tests in particular test file and then split tests based on tags.
|
|
2418
|
-
|
|
2419
|
-
This example is for knapsack_pro Regular Mode. You can also use knapsack_pro Queue Mode with tags.
|
|
2420
|
-
|
|
2421
|
-
Here is example of test file with specified tags for describe groups:
|
|
2422
|
-
|
|
2423
|
-
```ruby
|
|
2424
|
-
# spec/features/something_spec.rb
|
|
2425
|
-
describe 'Feature' do
|
|
2426
|
-
describe 'something A', :tagA do
|
|
2427
|
-
it {}
|
|
2428
|
-
it 'another test' {}
|
|
2429
|
-
end
|
|
2430
|
-
|
|
2431
|
-
describe 'something B', :tagB do
|
|
2432
|
-
it {}
|
|
2433
|
-
end
|
|
2434
|
-
|
|
2435
|
-
describe 'something else' do
|
|
2436
|
-
it {}
|
|
2437
|
-
end
|
|
2438
|
-
end
|
|
2439
|
-
```
|
|
2440
|
-
|
|
2441
|
-
You need to create API token per each tag. In this example we need 3 different API tokens.
|
|
2442
|
-
|
|
2443
|
-
You need to run below commands for each CI node.
|
|
2444
|
-
|
|
2445
|
-
```bash
|
|
2446
|
-
# run only tests with tagA
|
|
2447
|
-
KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC=api_key_for_tagA bundle exec rake "knapsack_pro:rspec[--tag tagA]"
|
|
2448
|
-
|
|
2449
|
-
# run only tests with tagB
|
|
2450
|
-
KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC=api_key_for_tagB bundle exec rake "knapsack_pro:rspec[--tag tagB]"
|
|
2451
|
-
|
|
2452
|
-
# run other tests without tag A & B
|
|
2453
|
-
KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC=api_key_for_tests_without_tags_A_and_B bundle exec rake "knapsack_pro:rspec[--tag ~tagA --tag ~tagB]"
|
|
2454
|
-
```
|
|
2455
|
-
|
|
2456
|
-
#### How to make knapsack_pro works for forked repositories of my project?
|
|
2457
|
-
|
|
2458
|
-
Imagine one of the scenarios, for this example I use the Travis-CI.
|
|
2459
|
-
|
|
2460
|
-
* We don’t want to have secrets like the `KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC` in `.travis.yml` in the codebase, because that code is also distributed to clients.
|
|
2461
|
-
* Adding it as env variables to Travis itself is tricky: It has to work for pull requests from developer’s forks into our main fork; this conflicts with the way Travis handles secrets. We also need a fallback if the token is not provided (when developers do builds within their own fork).
|
|
2462
|
-
|
|
2463
|
-
The solution for this problem is to set `KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC` as env variables in Travis for our main project.
|
|
2464
|
-
This won't be accessible on forked repositories so we will run knapsack_pro in fallback mode there.
|
|
2465
|
-
This way forked repositories have working test suite but without optimal test suite split across CI nodes.
|
|
2466
|
-
|
|
2467
|
-
Create the file `bin/knapsack_pro_rspec` with executable chmod in your main project repository.
|
|
2468
|
-
Below example is for rspec. You can change `$KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC` to `$KNAPSACK_PRO_TEST_SUITE_TOKEN_CUCUMBER` if you use cucumber etc.
|
|
2469
|
-
|
|
2470
|
-
```bash
|
|
2471
|
-
#!/bin/bash
|
|
2472
|
-
if [ "$KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC" = "" ]; then
|
|
2473
|
-
KNAPSACK_PRO_ENDPOINT=https://api-disabled-for-fork.knapsackpro.com \
|
|
2474
|
-
KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC=disabled-for-fork \
|
|
2475
|
-
KNAPSACK_PRO_MAX_REQUEST_RETRIES=0 \
|
|
2476
|
-
bundle exec rake knapsack_pro:rspec # use Regular Mode here always
|
|
2477
|
-
else
|
|
2478
|
-
# Regular Mode
|
|
2479
|
-
bundle exec rake knapsack_pro:rspec
|
|
2480
|
-
|
|
2481
|
-
# or you can use Queue Mode instead of Regular Mode if you like
|
|
2482
|
-
# bundle exec rake knapsack_pro:queue:rspec
|
|
2483
|
-
fi
|
|
2484
|
-
```
|
|
2485
|
-
|
|
2486
|
-
Now you can use `bin/knapsack_pro_rspec` command instead of `bundle exec rake knapsack_pro:rspec`.
|
|
2487
|
-
Remember to follow other steps required for your CI provider.
|
|
2488
|
-
|
|
2489
|
-
#### How to use junit formatter?
|
|
2490
|
-
|
|
2491
|
-
##### How to use junit formatter with knapsack_pro regular mode?
|
|
2492
|
-
|
|
2493
|
-
You can use junit formatter for rspec thanks to gem [rspec_junit_formatter](https://github.com/sj26/rspec_junit_formatter).
|
|
2494
|
-
Here you can find example how to generate `rspec.xml` file with junit format and at the same time show normal documentation format output for RSpec.
|
|
2495
|
-
|
|
2496
|
-
```bash
|
|
2497
|
-
# Regular Mode
|
|
2498
|
-
bundle exec rake "knapsack_pro:rspec[--format documentation --format RspecJunitFormatter --out tmp/rspec.xml]"
|
|
2499
|
-
```
|
|
2500
|
-
|
|
2501
|
-
##### How to use junit formatter with knapsack_pro queue mode?
|
|
2502
|
-
|
|
2503
|
-
You can use junit formatter for rspec thanks to gem [rspec_junit_formatter](https://github.com/sj26/rspec_junit_formatter).
|
|
2504
|
-
|
|
2505
|
-
```bash
|
|
2506
|
-
# Queue Mode
|
|
2507
|
-
bundle exec rake "knapsack_pro:queue:rspec[--format documentation --format RspecJunitFormatter --out tmp/rspec.xml]"
|
|
2508
|
-
```
|
|
2509
|
-
|
|
2510
|
-
The xml report will contain all tests executed across intermediate test subset runs based on work queue. You need to add after subset queue hook to rename `rspec.xml` to `rspec_final_results.xml` thanks to that the final results file will contain only single xml tag with all tests executed on the CI node. This is related to the way how queue mode works. Detailed explanation is in the [issue](https://github.com/KnapsackPro/knapsack_pro-ruby/issues/40).
|
|
2511
|
-
|
|
2512
|
-
```ruby
|
|
2513
|
-
# spec_helper.rb or rails_helper.rb
|
|
2514
|
-
|
|
2515
|
-
# TODO This must be the same path as value for rspec --out argument
|
|
2516
|
-
# Note the path should not contain sign ~, for instance path ~/project/tmp/rspec.xml may not work. Please use full path instead.
|
|
2517
|
-
TMP_RSPEC_XML_REPORT = 'tmp/rspec.xml'
|
|
2518
|
-
# move results to FINAL_RSPEC_XML_REPORT so the results won't accumulate with duplicated xml tags in TMP_RSPEC_XML_REPORT
|
|
2519
|
-
FINAL_RSPEC_XML_REPORT = 'tmp/rspec_final_results.xml'
|
|
2520
|
-
|
|
2521
|
-
KnapsackPro::Hooks::Queue.after_subset_queue do |queue_id, subset_queue_id|
|
|
2522
|
-
if File.exist?(TMP_RSPEC_XML_REPORT)
|
|
2523
|
-
FileUtils.mv(TMP_RSPEC_XML_REPORT, FINAL_RSPEC_XML_REPORT)
|
|
2524
|
-
end
|
|
2525
|
-
end
|
|
2526
|
-
```
|
|
2527
|
-
|
|
2528
|
-
###### How to use junit formatter with knapsack_pro queue mode when CI nodes use common local drive?
|
|
2529
|
-
|
|
2530
|
-
Note if you use a CI provider or your own CI solution that uses common local drive for all parallel CI nodes then above solution needs to be adjusted to produce report file with CI node index number in the file name to avoid file conflicts. Example file name with CI node index number: `tmp/rspec_final_results_N.xml`.
|
|
2531
|
-
|
|
2532
|
-
```bash
|
|
2533
|
-
# Queue Mode
|
|
2534
|
-
|
|
2535
|
-
# must be exported to read correctly the value in below knapsack_pro command
|
|
2536
|
-
export KNAPSACK_PRO_CI_NODE_INDEX=0
|
|
2537
|
-
# if your CI provider exposes CI node index under other environment variable name then you could use it instead
|
|
2538
|
-
|
|
2539
|
-
bundle exec rake "knapsack_pro:queue:rspec[--format documentation --format RspecJunitFormatter --out tmp/rspec_$KNAPSACK_PRO_CI_NODE_INDEX.xml]"
|
|
2540
|
-
```
|
|
2541
|
-
|
|
2542
|
-
In below code we use CI node index number in `TMP_RSPEC_XML_REPORT` and `FINAL_RSPEC_XML_REPORT`:
|
|
2543
|
-
|
|
2544
|
-
```ruby
|
|
2545
|
-
# spec_helper.rb or rails_helper.rb
|
|
2546
|
-
|
|
2547
|
-
# TODO This must be the same path as value for rspec --out argument
|
|
2548
|
-
# Note the path should not contain sign ~, for instance path ~/project/tmp/rspec.xml may not work. Please use full path instead.
|
|
2549
|
-
TMP_RSPEC_XML_REPORT = "tmp/rspec_#{ENV['KNAPSACK_PRO_CI_NODE_INDEX']}.xml"
|
|
2550
|
-
# move results to FINAL_RSPEC_XML_REPORT so the results won't accumulate with duplicated xml tags in TMP_RSPEC_XML_REPORT
|
|
2551
|
-
FINAL_RSPEC_XML_REPORT = "tmp/rspec_final_results_#{ENV['KNAPSACK_PRO_CI_NODE_INDEX']}.xml"
|
|
2552
|
-
|
|
2553
|
-
KnapsackPro::Hooks::Queue.after_subset_queue do |queue_id, subset_queue_id|
|
|
2554
|
-
if File.exist?(TMP_RSPEC_XML_REPORT)
|
|
2555
|
-
FileUtils.mv(TMP_RSPEC_XML_REPORT, FINAL_RSPEC_XML_REPORT)
|
|
2556
|
-
end
|
|
2557
|
-
end
|
|
2558
|
-
```
|
|
2559
|
-
|
|
2560
|
-
###### Why `tmp/rspec_final_results.xml` is corrupted when I use junit formatter with knapsack_pro queue mode?
|
|
2561
|
-
|
|
2562
|
-
The `tmp/rspec_final_results.xml` might be corrupted due syntax error in your test suite. First check if your test suite is green.
|
|
2563
|
-
Another reason might be that you did not configure the junit formatter as shown in the example for Queue Mode. Please check above 2 questions & answers explaing that.
|
|
2564
|
-
|
|
2565
|
-
###### How to use junit formatter with knapsack_pro queue mode in Cucumber?
|
|
2566
|
-
|
|
2567
|
-
Please provide in `--out` argument directory path where xml files for each test file will be created. It must be a directory in order to work in Queue Mode because in Queue Mode the Cucumber test runner is executed multiple times.
|
|
2568
|
-
Each time for set of tests fetched from Queue so it means multiple xml files will be created in junit format.
|
|
2569
|
-
|
|
2570
|
-
```bash
|
|
2571
|
-
bundle exec rake "knapsack_pro:queue:cucumber[--format junit --out tmp/test-reports/cucumber/queue_mode/]"
|
|
2572
|
-
```
|
|
2573
|
-
|
|
2574
|
-
#### How to use JSON formatter for RSpec?
|
|
2575
|
-
|
|
2576
|
-
##### How to use RSpec JSON formatter with knapsack_pro Queue Mode?
|
|
2577
|
-
|
|
2578
|
-
You need to specify `format` and `out` argument (it's important to provide both).
|
|
2579
|
-
|
|
2580
|
-
```bash
|
|
2581
|
-
# Queue Mode
|
|
2582
|
-
bundle exec rake "knapsack_pro:queue:rspec[--format documentation --format json --out tmp/rspec.json]"
|
|
2583
|
-
```
|
|
2584
|
-
|
|
2585
|
-
The JSON report will contain all tests executed across intermediate test subset runs based on work queue. You need to add after subset queue hook to rename `rspec.json` to `rspec_final_results.json` thanks to that the final results file will contain valid json with all tests executed on the CI node. This is related to the way how Queue Mode works. Detailed explanation is in the [issue](https://github.com/KnapsackPro/knapsack_pro-ruby/issues/40).
|
|
2586
|
-
|
|
2587
|
-
```ruby
|
|
2588
|
-
# spec_helper.rb or rails_helper.rb
|
|
2589
|
-
|
|
2590
|
-
# TODO This must be the same path as value for rspec --out argument
|
|
2591
|
-
# Note the path should not contain sign ~, for instance path ~/project/tmp/rspec.json may not work. Please use full path instead.
|
|
2592
|
-
TMP_RSPEC_JSON_REPORT = 'tmp/rspec.json'
|
|
2593
|
-
# move results to FINAL_RSPEC_JSON_REPORT so the results won't accumulate with duplicated JSON in TMP_RSPEC_JSON_REPORT
|
|
2594
|
-
FINAL_RSPEC_JSON_REPORT = 'tmp/rspec_final_results.json'
|
|
2595
|
-
|
|
2596
|
-
KnapsackPro::Hooks::Queue.after_subset_queue do |queue_id, subset_queue_id|
|
|
2597
|
-
if File.exist?(TMP_RSPEC_JSON_REPORT)
|
|
2598
|
-
FileUtils.mv(TMP_RSPEC_JSON_REPORT, FINAL_RSPEC_JSON_REPORT)
|
|
2599
|
-
end
|
|
2600
|
-
end
|
|
2601
|
-
```
|
|
2602
|
-
|
|
2603
|
-
###### How to use RSpec JSON formatter with knapsack_pro Queue Mode when CI nodes use common local drive?
|
|
2604
|
-
|
|
2605
|
-
Note if you use a CI provider or your own CI solution that uses common local drive for all parallel CI nodes then above solution needs to be adjusted to produce report file with CI node index number in the file name to avoid file conflicts. Example file name with CI node index number: `tmp/rspec_final_results_N.json`.
|
|
2606
|
-
|
|
2607
|
-
```
|
|
2608
|
-
# Queue Mode
|
|
2609
|
-
|
|
2610
|
-
# must be exported to read correctly the value in below knapsack_pro command
|
|
2611
|
-
export KNAPSACK_PRO_CI_NODE_INDEX=0
|
|
2612
|
-
# if your CI provider exposes CI node index under other environment variable name then you could use it instead
|
|
2613
|
-
|
|
2614
|
-
bundle exec rake "knapsack_pro:queue:rspec[--format documentation --format json --out tmp/rspec_$KNAPSACK_PRO_CI_NODE_INDEX.json]"
|
|
2615
|
-
```
|
|
2616
|
-
|
|
2617
|
-
In below code we use CI node index number in `TMP_RSPEC_JSON_REPORT` and `FINAL_RSPEC_JSON_REPORT`:
|
|
2618
|
-
|
|
2619
|
-
```ruby
|
|
2620
|
-
# spec_helper.rb or rails_helper.rb
|
|
2621
|
-
|
|
2622
|
-
# TODO This must be the same path as value for rspec --out argument
|
|
2623
|
-
# Note the path should not contain sign ~, for instance path ~/project/tmp/rspec.json may not work. Please use full path instead.
|
|
2624
|
-
TMP_RSPEC_JSON_REPORT = "tmp/rspec_#{ENV['KNAPSACK_PRO_CI_NODE_INDEX']}.json"
|
|
2625
|
-
# move results to FINAL_RSPEC_JSON_REPORT so the results won't accumulate with duplicated JSON in TMP_RSPEC_JSON_REPORT
|
|
2626
|
-
FINAL_RSPEC_JSON_REPORT = "tmp/rspec_final_results_#{ENV['KNAPSACK_PRO_CI_NODE_INDEX']}.json"
|
|
2627
|
-
|
|
2628
|
-
KnapsackPro::Hooks::Queue.after_subset_queue do |queue_id, subset_queue_id|
|
|
2629
|
-
if File.exist?(TMP_RSPEC_JSON_REPORT)
|
|
2630
|
-
FileUtils.mv(TMP_RSPEC_JSON_REPORT, FINAL_RSPEC_JSON_REPORT)
|
|
2631
|
-
end
|
|
2632
|
-
end
|
|
2633
|
-
```
|
|
2634
|
-
|
|
2635
|
-
#### How many API keys I need?
|
|
2636
|
-
|
|
2637
|
-
Basically you need as many API keys as you have steps in your build.
|
|
2638
|
-
|
|
2639
|
-
Here is example:
|
|
2640
|
-
|
|
2641
|
-
* Step 1. API_KEY_A for `bundle exec rake knapsack_pro:cucumber`
|
|
2642
|
-
* Step 2. API_KEY_B for `bundle exec rake knapsack_pro:rspec`
|
|
2643
|
-
* Step 3. API_KEY_C for `KNAPSACK_PRO_TEST_FILE_PATTERN="spec/features/*_spec.rb" bundle exec rake knapsack_pro:rspec`
|
|
2644
|
-
* Step 4. API_KEY_D for `bundle exec rake knapsack_pro:rspec[--tag tagA]`
|
|
2645
|
-
* Step 5. API_KEY_E for `bundle exec rake knapsack_pro:rspec[--tag ~tagA]`
|
|
2646
|
-
* Step 6. API_KEY_F for `bundle exec rake knapsack_pro:queue:rspec`
|
|
2647
|
-
|
|
2648
|
-
Note:
|
|
2649
|
-
|
|
2650
|
-
* If you specified `KNAPSACK_PRO_TEST_FILE_PATTERN` then you run subset of your whole test suite hence you need separate API key because we want to track only tests for this subset.
|
|
2651
|
-
* If you pass `--tag tagA` or `--tag ~tagA` then you run subset of your whole test suite hence you need separate API key.
|
|
2652
|
-
* If you use regular or queue mode then you need separate API key for each mode.
|
|
2653
|
-
|
|
2654
|
-
#### What is optimal order of test commands?
|
|
2655
|
-
|
|
2656
|
-
__Tip 1:__
|
|
2657
|
-
|
|
2658
|
-
I recommend to run first the test commands in the regular mode and later the commands in the queue mode.
|
|
2659
|
-
|
|
2660
|
-
* Step 1. `bundle exec rake knapsack_pro:cucumber` (regular mode)
|
|
2661
|
-
* Step 2. `bundle exec rake knapsack_pro:queue:rspec` (queue mode)
|
|
2662
|
-
|
|
2663
|
-
Thanks to that when for some reason the tests executed for cucumber in regular mode will not be well balanced across CI nodes (for instance when one of CI node has bad performance) then the rspec tests executed later in the queue mode will autobalance your build.
|
|
2664
|
-
|
|
2665
|
-
__Tip 2:__
|
|
2666
|
-
|
|
2667
|
-
When you have short test suite, for instance in javascript then you could distribute tests this way:
|
|
2668
|
-
|
|
2669
|
-
* CI 0
|
|
2670
|
-
* Step 1: `npm test`
|
|
2671
|
-
* Step 2: `bundle exec rake knapsack_pro:queue:rspec`
|
|
2672
|
-
|
|
2673
|
-
* CI 1
|
|
2674
|
-
* Step 1: `bundle exec rake knapsack_pro:queue:rspec`
|
|
2675
|
-
|
|
2676
|
-
You will run your javascript tests on single CI node and the knapsack_pro will auto-balance CI build with Queue Mode. Thanks to that CI build time execution will be flat and optimal (as fast as possible).
|
|
2677
|
-
|
|
2678
|
-
#### How to set `before(:suite)` and `after(:suite)` RSpec hooks in Queue Mode (Percy.io example)?
|
|
2679
|
-
|
|
2680
|
-
##### percy-capybara gem version < 4 (old)
|
|
2681
|
-
|
|
2682
|
-
Some tools like [Percy.io](https://percy.io/docs/clients/ruby/capybara-rails) requires to set hooks for RSpec `before(:suite)` and `after(:suite)`.
|
|
2683
|
-
Knapsack Pro Queue Mode runs subset of test files from the work queue many times. This means the RSpec hooks `before(:suite)` and `after(:suite)` will execute multiple times. If you want to run some code only once before Queue Mode starts work and after it finishes then you should do it this way:
|
|
2684
|
-
|
|
2685
|
-
```ruby
|
|
2686
|
-
# spec_helper.rb or rails_helper.rb
|
|
2687
|
-
# step for percy-capybara gem version < 4
|
|
2688
|
-
|
|
2689
|
-
KnapsackPro::Hooks::Queue.before_queue do |queue_id|
|
|
2690
|
-
# executes before Queue Mode starts work
|
|
2691
|
-
Percy::Capybara.initialize_build
|
|
2692
|
-
end
|
|
2693
|
-
|
|
2694
|
-
KnapsackPro::Hooks::Queue.after_queue do |queue_id|
|
|
2695
|
-
# executes after Queue Mode finishes work
|
|
2696
|
-
Percy::Capybara.finalize_build
|
|
2697
|
-
end
|
|
2698
|
-
```
|
|
2699
|
-
|
|
2700
|
-
##### percy-capybara gem version >= 4
|
|
2701
|
-
|
|
2702
|
-
If you use [percy-capybara 4.x](https://docs.percy.io/v1/docs/capybara) then you don't need to set RSpec hooks. Insted you need to run knapsack_pro via percy npm command.
|
|
2703
|
-
|
|
2704
|
-
```
|
|
2705
|
-
npx percy exec -- rake knapsack_pro:queue:rspec
|
|
2706
|
-
|
|
2707
|
-
# or you can use knapsack_pro binary version instead of rake task
|
|
2708
|
-
npx percy exec -- knapsack_pro queue:rspec
|
|
2709
|
-
```
|
|
2710
|
-
|
|
2711
|
-
Read more about [knapsack_pro binary version](#knapsack-pro-binary).
|
|
2712
|
-
|
|
2713
|
-
Also you need to follow [Percy step for parallelism](https://docs.percy.io/docs/parallel-test-suites#section-manual-configuration-with-environment-variables).
|
|
2714
|
-
|
|
2715
|
-
* `PERCY_PARALLEL_NONCE` - A unique identifier for this build. This can be anything, but it must be the same across parallel build nodes. Usually, this is just the CI build number or a shared timestamp. You can google environment variables for CI provider you use to check what's the env var for build ID.
|
|
2716
|
-
|
|
2717
|
-
You can also find CI build number for your CI provider in [knapsack_pro source code](https://github.com/KnapsackPro/knapsack_pro-ruby/tree/master/lib/knapsack_pro/config/ci). knapsack_pro has built in environment variables integration for various CI providers. See for example [CircleCI](https://github.com/KnapsackPro/knapsack_pro-ruby/blob/master/lib/knapsack_pro/config/ci/circle.rb) - look for method `node_build_id`.
|
|
2718
|
-
|
|
2719
|
-
```bash
|
|
2720
|
-
# example for using CircleCI build ID
|
|
2721
|
-
export PERCY_PARALLEL_NONCE=$CIRCLE_BUILD_NUM
|
|
2722
|
-
```
|
|
2723
|
-
|
|
2724
|
-
* `PERCY_PARALLEL_TOTAL` - The total number of parallel build nodes.
|
|
2725
|
-
|
|
2726
|
-
#### How to call `before(:suite)` and `after(:suite)` RSpec hooks only once in Queue Mode?
|
|
2727
|
-
|
|
2728
|
-
Knapsack Pro Queue Mode runs subset of test files from the work queue many times. This means the RSpec hooks `before(:suite)` and `after(:suite)` will be executed multiple times. If you want to run some code only once before Queue Mode starts work and after it finishes then you should do it this way:
|
|
2729
|
-
|
|
2730
|
-
```ruby
|
|
2731
|
-
# spec_helper.rb or rails_helper.rb
|
|
2732
|
-
|
|
2733
|
-
KnapsackPro::Hooks::Queue.before_queue do |queue_id|
|
|
2734
|
-
# This will be called only once before the tests started on the CI node.
|
|
2735
|
-
# It will be run inside of the RSpec before(:suite) block only once.
|
|
2736
|
-
# It means you will have access to whatever RSpec provides in the context of the before(:suite) block.
|
|
2737
|
-
end
|
|
2738
|
-
|
|
2739
|
-
KnapsackPro::Hooks::Queue.after_queue do |queue_id|
|
|
2740
|
-
# This will be called only once after test suite is completed.
|
|
2741
|
-
# Note this hook won't be called inside of RSpec after(:suite) block because
|
|
2742
|
-
# we are not able to determine which after(:suite) block will be called as the last one
|
|
2743
|
-
# due to the fact the Knapsack Pro Queue Mode allocates tests in dynamic way.
|
|
2744
|
-
end
|
|
2745
|
-
```
|
|
2746
|
-
|
|
2747
|
-
#### What hooks are supported in Queue Mode?
|
|
2748
|
-
|
|
2749
|
-
Note: Each hook type can be defined multiple times. For instance, if you define `KnapsackPro::Hooks::Queue.before_queue` twice then both block of code will be called when running your tests.
|
|
2750
|
-
|
|
2751
|
-
* RSpec in knapsack_pro Queue Mode supports hooks:
|
|
2752
|
-
|
|
2753
|
-
```ruby
|
|
2754
|
-
# spec_helper.rb or rails_helper.rb
|
|
2755
|
-
KnapsackPro::Hooks::Queue.before_queue do |queue_id|
|
|
2756
|
-
print 'Before Queue Hook - run before test suite'
|
|
2757
|
-
end
|
|
2758
|
-
|
|
2759
|
-
# this will be run after set of tests fetched from Queue has been executed
|
|
2760
|
-
KnapsackPro::Hooks::Queue.after_subset_queue do |queue_id, subset_queue_id|
|
|
2761
|
-
print 'After Subset Queue Hook - run after subset of test suite'
|
|
2762
|
-
end
|
|
2763
|
-
|
|
2764
|
-
KnapsackPro::Hooks::Queue.after_queue do |queue_id|
|
|
2765
|
-
print 'After Queue Hook - run after test suite'
|
|
2766
|
-
end
|
|
2767
|
-
```
|
|
2768
|
-
|
|
2769
|
-
* Minitest in knapsack_pro Queue Mode supports hooks:
|
|
2770
|
-
|
|
2771
|
-
```ruby
|
|
2772
|
-
# test/test_helper.rb
|
|
2773
|
-
KnapsackPro::Hooks::Queue.before_queue do |queue_id|
|
|
2774
|
-
print 'Before Queue Hook - run before test suite'
|
|
2775
|
-
end
|
|
2776
|
-
|
|
2777
|
-
KnapsackPro::Hooks::Queue.after_subset_queue do |queue_id, subset_queue_id|
|
|
2778
|
-
print 'After Subset Queue Hook - run after subset of test suite'
|
|
2779
|
-
end
|
|
2780
|
-
|
|
2781
|
-
KnapsackPro::Hooks::Queue.after_queue do |queue_id|
|
|
2782
|
-
print 'After Queue Hook - run after test suite'
|
|
2783
|
-
end
|
|
2784
|
-
```
|
|
2785
|
-
|
|
2786
|
-
* Cucumber in knapsack_pro Queue Mode supports hooks:
|
|
2787
|
-
|
|
2788
|
-
```ruby
|
|
2789
|
-
# features/support/knapsack_pro.rb
|
|
2790
|
-
KnapsackPro::Hooks::Queue.before_queue do |queue_id|
|
|
2791
|
-
print 'Before Queue Hook - run before test suite'
|
|
2792
|
-
end
|
|
2793
|
-
|
|
2794
|
-
KnapsackPro::Hooks::Queue.after_subset_queue do |queue_id, subset_queue_id|
|
|
2795
|
-
print 'After Subset Queue Hook - run after subset of test suite'
|
|
2796
|
-
end
|
|
2797
|
-
|
|
2798
|
-
# this hook is not supported and won't run
|
|
2799
|
-
KnapsackPro::Hooks::Queue.after_queue do |queue_id|
|
|
2800
|
-
print 'After Queue Hook - run after test suite'
|
|
2801
|
-
end
|
|
2802
|
-
```
|
|
2803
|
-
|
|
2804
|
-
#### How to run knapsack_pro with parallel_tests gem?
|
|
2805
|
-
|
|
2806
|
-
##### Should I use parallel_tests gem (what are pitfalls)?
|
|
2807
|
-
|
|
2808
|
-
If you plan to use parallel_tests please be careful how many parallel processes with running tests you will start on a single CI node.
|
|
2809
|
-
Often it happens that running 2 or more processes with tests using parallel_tests gem on the CI node that has low performance leads to slower execution of test suite. You can accidentally make your whole test suite running slower by using parallel_tests if you have not enough powerful CI server (slow CPU, not enough RAM, slow disk).
|
|
2810
|
-
|
|
2811
|
-
If you use parallel_tests and knapsack_pro you can see recorded tests timing in Knapsack Pro [user dashboard](https://knapsackpro.com/dashboard). See the "Build metrics" link next to your API token and check the last recorded CI build time. You will be able to see there how long each test files took to execute. If you notice that after adding parallel_tests gem your test files started to take more time than before it means you overloaded your CI server.
|
|
2812
|
-
|
|
2813
|
-
You should:
|
|
2814
|
-
|
|
2815
|
-
* reduce the number of parallel processes in parallel_tests gem
|
|
2816
|
-
* or buy a more powerful CI node to allow running more parallel processes (vertical scaling)
|
|
2817
|
-
* or don't use parallel_tests gem at all (recommended)
|
|
2818
|
-
|
|
2819
|
-
In case of tests execution time increase (slower tests) I recommend using more parallel nodes offered by your CI provider to scale your tests horizontally. Basically, adding parallel CI nodes instead of vertically adding more CPU/RAM to CI node is a better option. Parallel_tests gem has mixed output results from the parallel processes so it's easier to just browse tests output from parallel CI nodes when you scale horizontally by using knapsack_pro without parallel_tests.
|
|
2820
|
-
|
|
2821
|
-
If you want to use parallel_tests you can use it with Knapsack Pro Queue Mode to auto-balance tests split across parallel processes started by parallel_tests gem. See below tips on how to do it on [many parallel CI nodes where each node starts many parallel_tests processes](#parallel_tests-with-knapsack_pro-on-parallel-ci-nodes) or [on a single powerful CI server](#parallel_tests-with-knapsack_pro-on-single-ci-machine).
|
|
2822
|
-
|
|
2823
|
-
##### parallel_tests with knapsack_pro on parallel CI nodes
|
|
2824
|
-
|
|
2825
|
-
You can run knapsack_pro with [parallel_tests](https://github.com/grosser/parallel_tests) gem to run multiple concurrent knapsack_pro commands per CI node.
|
|
2826
|
-
|
|
2827
|
-
Let's consider this example. We have 2 CI node. On each CI node we want to run 2 concurrent knapsack_pro commands by parallel_tests gem (`PARALLEL_TESTS_CONCURRENCY=2`).
|
|
2828
|
-
This means we would have 4 parallel knapsack_pro commands in total across all CI nodes. So from knapsack_pro perspective you will have 4 nodes in total.
|
|
2829
|
-
|
|
2830
|
-
Create in your project directory an executable file `bin/parallel_tests`:
|
|
2831
|
-
|
|
2832
|
-
```bash
|
|
2833
|
-
#!/bin/bash
|
|
2834
|
-
# This file should be in bin/parallel_tests
|
|
2835
|
-
|
|
2836
|
-
# updates CI node total based on parallel_tests concurrency
|
|
2837
|
-
KNAPSACK_PRO_CI_NODE_TOTAL=$(( $PARALLEL_TESTS_CONCURRENCY * $KNAPSACK_PRO_CI_NODE_TOTAL ))
|
|
2838
|
-
|
|
2839
|
-
if [ "$TEST_ENV_NUMBER" == "" ]; then
|
|
2840
|
-
PARALLEL_TESTS_CONCURRENCY_INDEX=0
|
|
2841
|
-
else
|
|
2842
|
-
PARALLEL_TESTS_CONCURRENCY_INDEX=$(( $TEST_ENV_NUMBER - 1 ))
|
|
2843
|
-
fi
|
|
2844
|
-
|
|
2845
|
-
KNAPSACK_PRO_CI_NODE_INDEX=$(( $PARALLEL_TESTS_CONCURRENCY_INDEX + ($PARALLEL_TESTS_CONCURRENCY * $KNAPSACK_PRO_CI_NODE_INDEX) ))
|
|
2846
|
-
|
|
2847
|
-
# logs info about ENVs to ensure everything works
|
|
2848
|
-
echo KNAPSACK_PRO_CI_NODE_TOTAL=$KNAPSACK_PRO_CI_NODE_TOTAL KNAPSACK_PRO_CI_NODE_INDEX=$KNAPSACK_PRO_CI_NODE_INDEX PARALLEL_TESTS_CONCURRENCY=$PARALLEL_TESTS_CONCURRENCY
|
|
2849
|
-
|
|
2850
|
-
# you can customize your knapsack_pro command here to use regular or queue mode
|
|
2851
|
-
bundle exec rake knapsack_pro:queue:rspec
|
|
2852
|
-
```
|
|
2853
|
-
|
|
2854
|
-
Now you need to set parallel_tests command per CI node:
|
|
2855
|
-
|
|
2856
|
-
* CI node 0 (first CI node):
|
|
2857
|
-
|
|
2858
|
-
```bash
|
|
2859
|
-
export PARALLEL_TESTS_CONCURRENCY=2; # this must be export
|
|
2860
|
-
RAILS_ENV=test \
|
|
2861
|
-
KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC=xxx \
|
|
2862
|
-
KNAPSACK_PRO_CI_NODE_TOTAL=$YOUR_CI_NODE_TOTAL \
|
|
2863
|
-
KNAPSACK_PRO_CI_NODE_INDEX=$YOUR_CI_NODE_INDEX \
|
|
2864
|
-
bundle exec parallel_test -n $PARALLEL_TESTS_CONCURRENCY -e './bin/parallel_tests'
|
|
2865
|
-
```
|
|
2866
|
-
|
|
2867
|
-
* CI node 1 (second CI node):
|
|
2868
|
-
|
|
2869
|
-
```bash
|
|
2870
|
-
export PARALLEL_TESTS_CONCURRENCY=2; # this must be export
|
|
2871
|
-
RAILS_ENV=test \
|
|
2872
|
-
KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC=xxx \
|
|
2873
|
-
KNAPSACK_PRO_CI_NODE_TOTAL=$YOUR_CI_NODE_TOTAL \
|
|
2874
|
-
KNAPSACK_PRO_CI_NODE_INDEX=$YOUR_CI_NODE_INDEX \
|
|
2875
|
-
bundle exec parallel_test -n $PARALLEL_TESTS_CONCURRENCY -e './bin/parallel_tests'
|
|
2876
|
-
```
|
|
2877
|
-
|
|
2878
|
-
Please note you need to update `$YOUR_CI_NODE_TOTAL` and `$YOUR_CI_NODE_INDEX` to the ENVs provided by your CI provider. For instance in case of CircleCI it would be `$CIRCLE_NODE_TOTAL` and `$CIRCLE_NODE_INDEX`. Below is an example for CircleCI configuration:
|
|
2879
|
-
|
|
2880
|
-
```yaml
|
|
2881
|
-
# circle.yml for CircleCI 1.0
|
|
2882
|
-
# KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC=xxx can be set in CircleCI ENV settings
|
|
2883
|
-
test:
|
|
2884
|
-
override:
|
|
2885
|
-
- export PARALLEL_TESTS_CONCURRENCY=2; RAILS_ENV=test KNAPSACK_PRO_CI_NODE_TOTAL=$CIRCLE_NODE_TOTAL KNAPSACK_PRO_CI_NODE_INDEX=$CIRCLE_NODE_INDEX bundle exec parallel_test -n $PARALLEL_TESTS_CONCURRENCY -e './bin/parallel_tests':
|
|
2886
|
-
parallel: true # Caution: there are 8 spaces indentation!
|
|
2887
|
-
```
|
|
2888
|
-
|
|
2889
|
-
In summary, the `bin/parallel_tests` script will calculate a new values for `KNAPSAKC_PRO_*` environment variables and then run knapsack_pro command with them.
|
|
2890
|
-
To ensure everything works you can check output for each CI node.
|
|
2891
|
-
|
|
2892
|
-
* Expected output for CI node 0 (first CI node):
|
|
2893
|
-
|
|
2894
|
-
```
|
|
2895
|
-
KNAPSACK_PRO_CI_NODE_TOTAL=4 KNAPSACK_PRO_CI_NODE_INDEX=1 PARALLEL_TESTS_CONCURRENCY=2
|
|
2896
|
-
KNAPSACK_PRO_CI_NODE_TOTAL=4 KNAPSACK_PRO_CI_NODE_INDEX=0 PARALLEL_TESTS_CONCURRENCY=2
|
|
2897
|
-
(tests output here)
|
|
2898
|
-
```
|
|
2899
|
-
|
|
2900
|
-
* Expected output for CI node 1 (second CI node):
|
|
2901
|
-
|
|
2902
|
-
```
|
|
2903
|
-
KNAPSACK_PRO_CI_NODE_TOTAL=4 KNAPSACK_PRO_CI_NODE_INDEX=2 PARALLEL_TESTS_CONCURRENCY=2
|
|
2904
|
-
KNAPSACK_PRO_CI_NODE_TOTAL=4 KNAPSACK_PRO_CI_NODE_INDEX=3 PARALLEL_TESTS_CONCURRENCY=2
|
|
2905
|
-
(tests output here)
|
|
2906
|
-
```
|
|
2907
|
-
|
|
2908
|
-
##### parallel_tests with knapsack_pro on single CI machine
|
|
2909
|
-
|
|
2910
|
-
This tip is only relevant to you if you cannot use multiple parallel CI nodes on your CI provider. In such case, you can run your tests on a single CI machine with knapsack_pro Queue Mode in order to auto balance execution of tests and thanks to this better utilize CI machine resources.
|
|
2911
|
-
|
|
2912
|
-
You can run knapsack_pro with [parallel_tests](https://github.com/grosser/parallel_tests) gem to run multiple concurrent knapsack_pro commands on single CI node.
|
|
2913
|
-
|
|
2914
|
-
Create in your project directory an executable file `bin/parallel_tests_knapsack_pro_single_machine`:
|
|
2915
|
-
|
|
2916
|
-
```bash
|
|
2917
|
-
#!/bin/bash
|
|
2918
|
-
# bin/parallel_tests_knapsack_pro_single_machine
|
|
2919
|
-
|
|
2920
|
-
export KNAPSACK_PRO_CI_NODE_TOTAL=$PARALLEL_TESTS_CONCURRENCY
|
|
2921
|
-
|
|
2922
|
-
if [ "$TEST_ENV_NUMBER" == "" ]; then
|
|
2923
|
-
export KNAPSACK_PRO_CI_NODE_INDEX=0
|
|
2924
|
-
else
|
|
2925
|
-
export KNAPSACK_PRO_CI_NODE_INDEX=$(( $TEST_ENV_NUMBER - 1 ))
|
|
2926
|
-
fi
|
|
2927
|
-
|
|
2928
|
-
echo KNAPSACK_PRO_CI_NODE_TOTAL=$KNAPSACK_PRO_CI_NODE_TOTAL KNAPSACK_PRO_CI_NODE_INDEX=$KNAPSACK_PRO_CI_NODE_INDEX PARALLEL_TESTS_CONCURRENCY=$PARALLEL_TESTS_CONCURRENCY
|
|
2929
|
-
|
|
2930
|
-
bundle exec rake knapsack_pro:queue:rspec
|
|
2931
|
-
```
|
|
2932
|
-
|
|
2933
|
-
Then you need another script `bin/parallel_tests_knapsack_pro_single_machine_run` to run above script with `parallel_tests`:
|
|
2934
|
-
|
|
2935
|
-
```bash
|
|
2936
|
-
#!/bin/bash
|
|
2937
|
-
# bin/parallel_tests_knapsack_pro_single_machine_run
|
|
2938
|
-
|
|
2939
|
-
export PARALLEL_TESTS_CONCURRENCY=2;
|
|
2940
|
-
|
|
2941
|
-
RAILS_ENV=test \
|
|
2942
|
-
KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC=xxx \
|
|
2943
|
-
KNAPSACK_PRO_REPOSITORY_ADAPTER=git \
|
|
2944
|
-
KNAPSACK_PRO_PROJECT_DIR=/home/user/rails-app-repo \
|
|
2945
|
-
PARALLEL_TESTS_CONCURRENCY=$PARALLEL_TESTS_CONCURRENCY \
|
|
2946
|
-
bundle exec parallel_test -n $PARALLEL_TESTS_CONCURRENCY -e './bin/parallel_tests_knapsack_pro_single_machine'
|
|
2947
|
-
```
|
|
2948
|
-
|
|
2949
|
-
Now you can run `bin/parallel_tests_knapsack_pro_single_machine_run` and it will execute 2 parallel processes with `parallel_tests`. Each process will run knapsack_pro Queue Mode to autobalance test files distribution across the processes.
|
|
2950
|
-
|
|
2951
|
-
#### How to retry failed tests (flaky tests)?
|
|
2952
|
-
|
|
2953
|
-
Flaky (nondeterministic) tests, are tests that exhibit both a passing and a failing result with the same code.
|
|
2954
|
-
|
|
2955
|
-
I recommend to use [rspec-retry](https://github.com/NoRedInk/rspec-retry) gem that can retry failing test. It can be useful for randomly failing features specs. For instance you can configure it to retry 3 times features test before marking it as failing.
|
|
2956
|
-
|
|
2957
|
-
Alternative way is to use built into [RSpec only failures option](https://relishapp.com/rspec/rspec-core/docs/command-line/only-failures) to rerun failed tests.
|
|
2958
|
-
|
|
2959
|
-
Please add to your RSpec configuration:
|
|
2960
|
-
|
|
2961
|
-
```ruby
|
|
2962
|
-
RSpec.configure do |c|
|
|
2963
|
-
c.example_status_persistence_file_path = "tmp/rspec_examples.txt"
|
|
2964
|
-
end
|
|
2965
|
-
```
|
|
2966
|
-
|
|
2967
|
-
Then you can execute rspec with only failed tests after main knapsack_pro command finish.
|
|
2968
|
-
|
|
2969
|
-
```bash
|
|
2970
|
-
# Run knapsack_pro in Queue Mode and it will save failed tests in tmp/rspec_examples.txt
|
|
2971
|
-
bundle exec rake knapsack_pro:queue:rspec
|
|
2972
|
-
|
|
2973
|
-
# run only failed tests from tmp/rspec_examples.txt
|
|
2974
|
-
bundle exec rspec --only-failures
|
|
2975
|
-
```
|
|
2976
|
-
|
|
2977
|
-
#### How can I run tests from multiple directories?
|
|
2978
|
-
|
|
2979
|
-
The test file pattern config option supports any glob pattern handled by [`Dir.glob`](http://ruby-doc.org/core-2.4.1/Dir.html#method-c-glob) and can be configured to pull test files from multiple directories. An example of this when using RSpec would be `"{spec,engines/*/spec}/**/*_spec.rb"`. For complex cases like this, the test directory can't be extracted and must be specified manually using the `KNAPSACK_PRO_TEST_DIR` environment variable:
|
|
2980
|
-
|
|
2981
|
-
```
|
|
2982
|
-
# This is example where you have in engines directory multiple projects
|
|
2983
|
-
# and each project directory has a spec folder and you would like to run tests for it.
|
|
2984
|
-
# You want to use the spec_helper from the main spec directory.
|
|
2985
|
-
#
|
|
2986
|
-
# Tree:
|
|
2987
|
-
# * spec
|
|
2988
|
-
# * engines
|
|
2989
|
-
# * project_a
|
|
2990
|
-
# * spec
|
|
2991
|
-
# * project_b
|
|
2992
|
-
# * spec
|
|
2993
|
-
$ KNAPSACK_PRO_TEST_DIR=spec KNAPSACK_PRO_TEST_FILE_PATTERN="{spec,engines/*/spec}/**/*_spec.rb" bundle exec rake knapsack_pro:queue:rspec
|
|
2994
|
-
```
|
|
2995
|
-
|
|
2996
|
-
`KNAPSACK_PRO_TEST_DIR` will be your default path for rspec so you should put there your `spec_helper.rb`. Please ensure you will require it in your test files this way if something doesn't work:
|
|
2997
|
-
|
|
2998
|
-
```ruby
|
|
2999
|
-
# good
|
|
3000
|
-
require_relative 'spec_helper'
|
|
3001
|
-
|
|
3002
|
-
# bad - won't work
|
|
3003
|
-
require 'spec_helper'
|
|
3004
|
-
```
|
|
3005
|
-
|
|
3006
|
-
#### Why I don't see all test files being recorded in user dashboard
|
|
3007
|
-
|
|
3008
|
-
If you open `Build metrics` for particular API token at [user dashboard](https://knapsackpro.com/dashboard) and you don't see all time execution data recorded for all test files then you should know that knapsack_pro version older than [`1.0.2`](https://github.com/KnapsackPro/knapsack_pro-ruby/blob/master/CHANGELOG.md#102) does not track test files with empty content or when the test file contains only pending tests.
|
|
3009
|
-
|
|
3010
|
-
The test files with pending tests are executed so you will see it in RSpec output but just not recorded in Knapsack Pro API because there is nothing to record time for.
|
|
3011
|
-
|
|
3012
|
-
We recommend to update to the latest version of knapsack_pro.
|
|
3013
|
-
|
|
3014
|
-
Please check also this question [why you may don't see time execution data](#why-i-dont-see-collected-time-execution-data-for-my-build-in-user-dashboard) in your dashboard.
|
|
3015
|
-
|
|
3016
|
-
#### Why when I use 2 different CI providers then not all test files are executed?
|
|
3017
|
-
|
|
3018
|
-
Please ensure you use 2 different API token per test suite. If you use 2 CI providers for instance CircleCI and TravisCI at the same time and you run the RSpec test suite then you need to have separate API token for RSpec executed on CircleCI and a separate API token for RSpec test suite executed on the TravisCI.
|
|
3019
|
-
|
|
3020
|
-
#### How to run only RSpec feature tests or non feature tests?
|
|
3021
|
-
|
|
3022
|
-
**Option 1: RSpec tags**
|
|
3023
|
-
|
|
3024
|
-
You can run just feature tests this way. You need to generate a separate API token for it.
|
|
3025
|
-
|
|
3026
|
-
```
|
|
3027
|
-
KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC=$API_TOKEN_FOR_FEATURE_TESTS bundle exec rake "knapsack_pro:queue:rspec[--tag type:feature]"
|
|
3028
|
-
```
|
|
3029
|
-
|
|
3030
|
-
If you would like to run only non feature tests then use negation `~type:feature`:
|
|
3031
|
-
|
|
3032
|
-
```
|
|
3033
|
-
KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC=$API_TOKEN_FOR_NON_FEATURE_TESTS bundle exec rake "knapsack_pro:queue:rspec[--tag ~type:feature]"
|
|
3034
|
-
```
|
|
3035
|
-
|
|
3036
|
-
Note above examples are for knapsack_pro Queue Mode and when you will run tests you may notice that all test files are run by RSpec but only tests specified by tag like `tag type:feature` will be executed. Basically RSpec will just load all files but run just specified tags.
|
|
3037
|
-
|
|
3038
|
-
**Option 2: specify directory pattern**
|
|
3039
|
-
|
|
3040
|
-
Another approach is to explicitly specify which files should be executed.
|
|
3041
|
-
|
|
3042
|
-
Run all specs from multiple directories except `spec/features` directory which is not listed below.
|
|
3043
|
-
If you would like to run additional directory please add it after comma in `KNAPSACK_PRO_TEST_FILE_PATTERN`.
|
|
3044
|
-
Ensure the list of directories match your spec directory structure.
|
|
3045
|
-
|
|
3046
|
-
```bash
|
|
3047
|
-
KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC=$API_TOKEN_FOR_NON_FEATURE_TESTS \
|
|
3048
|
-
KNAPSACK_PRO_TEST_DIR=spec \
|
|
3049
|
-
KNAPSACK_PRO_TEST_FILE_PATTERN="{spec/*_spec.rb,spec/controllers/**/*_spec.rb,spec/mailers/**/*_spec.rb,spec/models/**/*_spec.rb,spec/presenters/**/*_spec.rb,spec/requests/**/*_spec.rb,spec/routing/**/*_spec.rb,spec/services/**/*_spec.rb,spec/workers/**/*_spec.rb,spec/jobs/**/*_spec.rb}" \
|
|
3050
|
-
bundle exec rake knapsack_pro:queue:rspec
|
|
3051
|
-
```
|
|
3052
|
-
|
|
3053
|
-
When you would like to run tests only from `spec/features` directory then run:
|
|
3054
|
-
|
|
3055
|
-
```bash
|
|
3056
|
-
KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC=$API_TOKEN_FOR_FEATURE_TESTS \
|
|
3057
|
-
KNAPSACK_PRO_TEST_DIR=spec \
|
|
3058
|
-
KNAPSACK_PRO_TEST_FILE_PATTERN="spec/features/**{,/*/**}/*_spec.rb" \
|
|
3059
|
-
bundle exec rake knapsack_pro:queue:rspec
|
|
3060
|
-
```
|
|
3061
|
-
|
|
3062
|
-
You can also learn [how to use exclude pattern](#how-to-exclude-tests-from-running-them).
|
|
3063
|
-
|
|
3064
|
-
#### How to exclude tests from running them?
|
|
3065
|
-
|
|
3066
|
-
For instance you would like to run all tests except tests in `features` directory then you could do:
|
|
3067
|
-
|
|
3068
|
-
```bash
|
|
3069
|
-
KNAPSACK_PRO_TEST_FILE_EXCLUDE_PATTERN="spec/features/**{,/*/**}/*_spec.rb" \
|
|
3070
|
-
bundle exec rake knapsack_pro:queue:rspec
|
|
3071
|
-
```
|
|
3072
|
-
|
|
3073
|
-
You can define at the same time the pattern for tests you would like to run and the exclude pattern. For instance run all controller tests except admin controller tests.
|
|
3074
|
-
|
|
3075
|
-
```bash
|
|
3076
|
-
KNAPSACK_PRO_TEST_FILE_PATTERN="spec/controllers/**{,/*/**}/*_spec.rb" \
|
|
3077
|
-
KNAPSACK_PRO_TEST_FILE_EXCLUDE_PATTERN="spec/controllers/admin/**{,/*/**}/*_spec.rb" \
|
|
3078
|
-
bundle exec rake knapsack_pro:queue:rspec
|
|
3079
|
-
```
|
|
3080
|
-
|
|
3081
|
-
The test file pattern and exclude pattern support any glob pattern handled by [`Dir.glob`](http://ruby-doc.org/core-2.4.1/Dir.html#method-c-glob).
|
|
3082
|
-
|
|
3083
|
-
#### How to run a specific list of test files or only some tests from test file?
|
|
3084
|
-
|
|
3085
|
-
:information_source: If you don't want to use the pattern [`KNAPSACK_PRO_TEST_FILE_PATTERN`](#how-can-i-run-tests-from-multiple-directories) to define a list of tests to run then read below two options.
|
|
3086
|
-
|
|
3087
|
-
**Option 1:**
|
|
3088
|
-
|
|
3089
|
-
If you want to run a specific list of test files that are explicitly defined by you or auto-generated by some kind of script you created then please use:
|
|
3090
|
-
|
|
3091
|
-
`KNAPSACK_PRO_TEST_FILE_LIST=spec/features/dashboard_spec.rb,spec/models/user.rb:10,spec/models/user.rb:29`
|
|
3092
|
-
|
|
3093
|
-
Note `KNAPSACK_PRO_TEST_FILE_LIST` must be a list of test files comma separated. You can provide line number for tests inside of spec file in case of RSpec (this way you can run only one test or a group of tests from RSpec spec file). You can provide the same file a few times with different test line number.
|
|
3094
|
-
|
|
3095
|
-
**Option 2:**
|
|
3096
|
-
|
|
3097
|
-
Similarly, you can also provide a source file containing the test files that you would like to run. For example:
|
|
3098
|
-
`KNAPSACK_PRO_TEST_FILE_LIST_SOURCE_FILE=spec/fixtures/test_file_list_source_file.txt`
|
|
3099
|
-
And the content of the source file can be any of the format below:
|
|
3100
|
-
|
|
3101
|
-
```
|
|
3102
|
-
./spec/test1_spec.rb
|
|
3103
|
-
spec/test2_spec.rb[1]
|
|
3104
|
-
./spec/test3_spec.rb[1:2:3:4]
|
|
3105
|
-
./spec/test4_spec.rb:4
|
|
3106
|
-
./spec/test4_spec.rb:5
|
|
3107
|
-
```
|
|
3108
|
-
|
|
3109
|
-
> Note that each of the line must be ending with `\n` the new line.
|
|
3110
|
-
|
|
3111
|
-
Note when you set `KNAPSACK_PRO_TEST_FILE_LIST` or `KNAPSACK_PRO_TEST_FILE_LIST_SOURCE_FILE` then below environment variables are ignored:
|
|
3112
|
-
|
|
3113
|
-
* `KNAPSACK_PRO_TEST_FILE_PATTERN`
|
|
3114
|
-
* `KNAPSACK_PRO_TEST_FILE_EXCLUDE_PATTERN`
|
|
3115
|
-
|
|
3116
|
-
#### How to run knapsack_pro only on a few parallel CI nodes instead of all?
|
|
3117
|
-
|
|
3118
|
-
You may want to run knapsack_pro only on a few CI nodes when you would like to run a different job on other CI nodes.
|
|
3119
|
-
|
|
3120
|
-
For instance, you have 3 parallel CI nodes. You would like to run knapsack_pro only on two CI nodes. The last CI node you want to use for the different job like running linters etc.
|
|
3121
|
-
|
|
3122
|
-
In such case, you can override the number of total CI nodes available by your CI provider. For instance, Heroku CI provider exposes in ENV variables `CI_NODE_TOTAL=3`.
|
|
3123
|
-
|
|
3124
|
-
You can then run knapsack_pro command this way on the first and the second CI node:
|
|
3125
|
-
|
|
3126
|
-
```
|
|
3127
|
-
KNAPSACK_PRO_CI_NODE_TOTAL=$((CI_NODE_TOTAL-1)) bundle exec rake knapsack_pro:rspec
|
|
3128
|
-
```
|
|
3129
|
-
|
|
3130
|
-
We decrease the number of CI node total by 1 that knapsack_pro can see. This way you can run tests with knapsack_pro only on two CI nodes.
|
|
3131
|
-
On the 3rd CI node, you can run other things like linters etc.
|
|
3132
|
-
|
|
3133
|
-
If you would like to check what is the CI node total ENV variable name exposed by your CI provider you can check that in your CI provider environment variables docs
|
|
3134
|
-
or preview the [ENV variables that knapsack_pro can read](https://github.com/KnapsackPro/knapsack_pro-ruby/tree/master/lib/knapsack_pro/config/ci) for supported CI providers.
|
|
3135
|
-
|
|
3136
|
-
If you use for instance Heroku CI that allows you to provide only one test command you can make a bash script to control what's executed on particular CI node:
|
|
3137
|
-
|
|
3138
|
-
```bash
|
|
3139
|
-
#!/bin/bash
|
|
3140
|
-
# add this file in bin/knapsack_pro_rspec_and_npm_test and change chmod
|
|
3141
|
-
# $ chmod a+x bin/knapsack_pro_rspec_and_npm_test
|
|
3142
|
-
|
|
3143
|
-
# 15 is last CI node (index starts from 0, so in total we have 16 parallel Heroku dynos)
|
|
3144
|
-
if [ "$CI_NODE_INDEX" == "15" ]; then
|
|
3145
|
-
# run npm tests on the last CI node
|
|
3146
|
-
npm test
|
|
3147
|
-
else
|
|
3148
|
-
KNAPSACK_PRO_CI_NODE_TOTAL=$((CI_NODE_TOTAL-1)) bundle exec rake knapsack_pro:queue:rspec
|
|
3149
|
-
fi
|
|
3150
|
-
```
|
|
3151
|
-
|
|
3152
|
-
then in your Heroku CI config `app.json` set:
|
|
3153
|
-
|
|
3154
|
-
```
|
|
3155
|
-
"scripts": {
|
|
3156
|
-
"test": "bin/knapsack_pro_rspec_and_npm_test"
|
|
3157
|
-
}
|
|
3158
|
-
```
|
|
3159
|
-
|
|
3160
|
-
#### How to use CodeClimate with knapsack_pro?
|
|
3161
|
-
|
|
3162
|
-
You can check articles about CodeClimate configuration with knapsack_pro gem:
|
|
3163
|
-
* [CodeClimate and CircleCI 2.0 parallel builds config for RSpec with SimpleCov and JUnit formatter](https://docs.knapsackpro.com/2019/codeclimate-and-circleci-2-0-parallel-builds-config-for-rspec-with-simplecov-and-junit-formatter)
|
|
3164
|
-
* [How to merge CodeClimate reports for parallel jobs (CI nodes) on Semaphore CI 2.0](https://docs.knapsackpro.com/2019/how-to-merge-codeclimate-reports-for-parallel-jobs-ci-nodes).
|
|
3165
|
-
|
|
3166
|
-
#### How to use simplecov in Queue Mode?
|
|
3167
|
-
|
|
3168
|
-
If you would like to make [simplecov](https://github.com/colszowka/simplecov) gem work with knapsack_pro Queue Mode to correctly track code coverage for parallel CI nodes please do:
|
|
3169
|
-
|
|
3170
|
-
```ruby
|
|
3171
|
-
# spec_helper.rb or rails_helper.rb
|
|
3172
|
-
require 'knapsack_pro'
|
|
3173
|
-
|
|
3174
|
-
require 'simplecov'
|
|
3175
|
-
SimpleCov.start
|
|
3176
|
-
|
|
3177
|
-
KnapsackPro::Hooks::Queue.before_queue do |queue_id|
|
|
3178
|
-
SimpleCov.command_name("rspec_ci_node_#{KnapsackPro::Config::Env.ci_node_index}")
|
|
3179
|
-
end
|
|
3180
|
-
```
|
|
3181
|
-
|
|
3182
|
-
This way there should be no conflict between code coverage reports generated per CI node index even when you use the same local drive (for instance you use Jenkins as your CI provider). The simplecov will generate single report at `coverage/index.html` with merged data from parallel CI nodes.
|
|
3183
|
-
|
|
3184
|
-
#### Do I need to use separate API token for Queue Mode and Regular Mode?
|
|
3185
|
-
|
|
3186
|
-
I recommend to record timing of a new test suite with `API token A` and knapsack_pro Regular Mode. After you recorded test suite timing then you should use the `API token A` to run your tests in knapsack_pro Queue Mode. This way Queue Mode will leverage test suite timing recorded in a fast way with Regular Mode so the first run in Queue Mode won't be slow due to recording test files timing for the first time.
|
|
3187
|
-
|
|
3188
|
-
When you want to go back from Queue Mode to Regular Mode then the fact of using the same API token could cause edge cases that some builds might not be well balanced in Regular Mode. That is why I recommend using separate API token for Regular Mode and Queue Mode. If you plan to use only Queue Mode then no worry.
|
|
3189
|
-
|
|
3190
|
-
#### How to stop running tests on the first failed test (fail fast tests in RSpec)?
|
|
3191
|
-
|
|
3192
|
-
If you want to stop running tests as soon as one of it fails then you can pass [--fail-fast](https://relishapp.com/rspec/rspec-core/docs/command-line/fail-fast-option) RSpec option to knapsack_pro:
|
|
3193
|
-
|
|
3194
|
-
```
|
|
3195
|
-
# Regular Mode
|
|
3196
|
-
bundle exec rake "knapsack_pro:rspec[--fail-fast]"
|
|
3197
|
-
|
|
3198
|
-
# Queue Mode
|
|
3199
|
-
bundle exec rake "knapsack_pro:queue:rspec[--fail-fast]"
|
|
3200
|
-
```
|
|
3201
|
-
|
|
3202
|
-
You may add a parameter to tell RSpec to stop running the test suite after N failed tests, for example: `--fail-fast=3`.
|
|
3203
|
-
|
|
3204
|
-
```
|
|
3205
|
-
Note there is no = sign on purpose here:
|
|
3206
|
-
|
|
3207
|
-
# Regular Mode
|
|
3208
|
-
bundle exec rake "knapsack_pro:rspec[--fail-fast 3]"
|
|
3209
|
-
|
|
3210
|
-
# Queue Mode
|
|
3211
|
-
bundle exec rake "knapsack_pro:queue:rspec[--fail-fast 3]"
|
|
3212
|
-
```
|
|
3213
|
-
|
|
3214
|
-
There is a downside to it. If you stop running tests then tests that were never run will have no recorded timing of execution and because of that, the future CI build might have tests split across CI nodes in no optimal way.
|
|
3215
|
-
|
|
3216
|
-
### Questions around data usage and security
|
|
3217
|
-
|
|
3218
|
-
#### What data is sent to your servers?
|
|
3219
|
-
|
|
3220
|
-
The knapsack_pro gem sends branch name, commit hash, CI total node number, CI index node number, the test file paths like `spec/models/user_spec.rb` and the time execution of each test file path as a float.
|
|
3221
|
-
|
|
3222
|
-
Here is the [full specification of the API](http://docs.knapsackpro.com/api/v1/) used by knapsack_pro gem.
|
|
3223
|
-
|
|
3224
|
-
#### How is that data secured?
|
|
3225
|
-
|
|
3226
|
-
The test file paths and/or branch names can be [encrypted](#test-file-names-encryption) on your CI node with a salt and later send to knapsackpro.com API.
|
|
3227
|
-
You generate the salt locally and __only you__ can decrypt the test file paths or branch names with the salt. Here you can [see how the data are encrypted](lib/knapsack_pro/crypto/digestor.rb).
|
|
3228
|
-
|
|
3229
|
-
Connection with knapsackpro.com server is via https.
|
|
3230
|
-
|
|
3231
|
-
Regarding payments we use the BraintreePayments.com and they store credit cards and your private information.
|
|
3232
|
-
|
|
3233
|
-
#### Who has access to the data?
|
|
3234
|
-
|
|
3235
|
-
I’m the only admin so I can preview data in case you need help with debugging some problem etc. I’m not able to decrypt them without knowing the salt.
|
|
3236
|
-
|
|
3237
|
-
When you sign in to your user dashboard then you can preview data for recent CI builds. If the test file paths are encrypted then you only see hashes for test file paths.
|
|
3238
|
-
You need to [decrypt](#how-to-debug-test-file-names) them locally on your machine to find out what each test file hash is.
|
|
3239
|
-
|
|
3240
1675
|
## Gem tests
|
|
3241
1676
|
|
|
3242
1677
|
### Spec
|