Knapsack Pro

Check out the new docs for the updated documentation.

FAQ / knapsack_pro / General questions for knapsack_pro gem

How to make knapsack_pro works for forked repositories of my project?

Imagine one of the scenarios, for this example I use the Travis-CI.

  • 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.
  • 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).

The solution for this problem is to set KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC as env variables in Travis for our main project. This won't be accessible on forked repositories so we will run knapsack_pro in Fallback Mode there. This way forked repositories have working test suite but without optimal test suite split across CI nodes.

Create the file bin/knapsack_pro_rspec with executable chmod in your main project repository. 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.

    bundle exec rake knapsack_pro:rspec # use Regular Mode here always
    # Regular Mode
    bundle exec rake knapsack_pro:rspec

    # or you can use Queue Mode instead of Regular Mode if you like
    # bundle exec rake knapsack_pro:queue:rspec

Now you can use bin/knapsack_pro_rspec command instead of bundle exec rake knapsack_pro:rspec. Remember to follow other steps required for your CI provider.

# General questions for knapsack_pro gem
See questions outside of this category

Start using Knapsack Pro

Sign up and speed up your tests.