FAQ / knapsack_pro / Queue Mode problems & solutions for knapsack_pro gem

If one of the parallel CI nodes starts work very late after other parallel CI nodes already finished work then tests are executed twice on late CI node in Knapsack Pro Queue Mode

Some of CI providers have a problem with starting parallel CI nodes as soon as possible. For instance, you have a fixed pool of parallel CI nodes shared with many CI builds and sometimes CI build has started work even the pool has not enough available parallel CI nodes at the moment. Another case is when the CI provider infrastructure is overloaded which can lead to some parallel CI nodes starting work later than others.

Do you have the CI server that does not start all parallel CI nodes at the same time and one of your parallel CI nodes will start work very late after all other parallel CI nodes already finished consuming tests from the Knapsack Pro Queue? In such a case, if you would use default KNAPSACK_PRO_FIXED_QUEUE_SPLIT=false then the very late CI node would start running all tests again based on a new Queue which means you would run test suite twice. This problem can happen if your test suite is very small and differences in the start time of parallel CI nodes are very big.

You should set KNAPSACK_PRO_FIXED_QUEUE_SPLIT=true to ensure the very late parallel CI node won't run tests again if the Queue was already consumed. The downside of this is that you won't be able to run 2nd CI build for the same set of values git commit/branch/ci node total number with a dynamic test suite split way if your CI provider does not expose unique CI build ID. Instead, the tests will be run assigned to the same parallel CI node indexes with the same order as it was recorded for the first time.

Knapsack Pro tries to detect CI build ID from the environment variables of your CI provider. Here you can check if your CI provider exposes CI build ID. If you CI provider won't provide CI build ID you can set KNAPSACK_PRO_CI_NODE_BUILD_ID that must be unique for a CI build and must be the same across parallel CI nodes within the CI build.

  • KNAPSACK_PRO_CI_NODE_BUILD_ID - a unique ID for your CI build. All parallel CI nodes being part of single CI build must have the same node build ID. Example how to generate node build ID: KNAPSACK_PRO_CI_NODE_BUILD_ID=$(openssl rand - base64 32).

Queue Mode problems & solutions for knapsack_pro gem
See questions outside of this category

Start using Knapsack Pro

Sign up and speed up your tests.