Knapsack Pro API documentation

/build_subsets

/build_subsets post

post

Endpoint expects partial test suite execution data for particular test build.

For instance send here data collected after execution half of test suite on the first CI node. Send here also data collected for the second half of the test suite executed on the second CI node.

We will merge the data automatically to have complete information about the particular build.

Endpoint expects partial test suite execution data for particular test build.

For instance send here data collected after execution half of test suite on the first CI node. Send here also data collected for the second half of the test suite executed on the second CI node.

We will merge the data automatically to have complete information about the particular build.

Request
Response

Headers

KNAPSACK-PRO-CLIENT-NAME: (string)
It is the name of library you use to connect with the API.
Example:
```
knapsack_pro-ruby
```
KNAPSACK-PRO-CLIENT-VERSION: (string)
It is the version of the library you use to connect with the API.
Example:
```
1.0.0
```
KNAPSACK-PRO-TEST-SUITE-TOKEN: required(string)
Test suite token for your project. You can get it on the user dashboard.
Example:
```
e5311882cbba506223ee8036fa68dc13
```
KNAPSACK-PRO-CI-PROVIDER: (string)
It is the name of the CI provider.
Example:
```
GitHub Actions
```

Query Parameters

commit_hash: required(string)
The most recent hash commit in your project.
You are running tests on the codebase with latest commit pointed to the commit_hash.
Example:
```
6e3396177d9f8ca87e2b93b4b0a25babd09d574d
```
branch: required(string)
You are running tests on this branch.
Example:
```
master
```
node_total: required(integer)
Total number of CI nodes you have.
For instance if you want to parallelize your test suite across 4 servers then node_total is 4.
Example:
```
4
```
node_index: required(integer)
Index of current CI node where part of the test suite where executed.
node_index starts from 0 so in case when node_total is 4 then max node_index is 3.
Example:
```
0
```

test_files: required(string)

JSON array with objects. Each object contains test file path and execution time for the test file.

Example contains only part of the test suite. The part of tests was executed on the CI node for specified node_index.

Example:

[
  {
    "path": "test/fast/a_test.rb",
    "time_execution": 0.2015
  },
  {
    "path": "test/fast/b_test.rb",
    "time_execution": 0.04
  },
  {
    "path": "test/slow/c_test.rb",
    "time_execution": 6.2120
  },
  {
    "path": "test/slow/d_test.rb",
    "time_execution": 4.3703
  }
]

Body

Media type: application/json

Type:

{
  "commit_hash": "6e3396177d9f8ca87e2b93b4b0a25babd09d574d",
  "branch": "master",
  "node_total": "4",
  "node_index": "0",
  "test_files": [
    {
      "path": "test/fast/a_test.rb",
      "time_execution": 0.2015
    },
    {
      "path": "test/fast/b_test.rb",
      "time_execution": 0.04
    },
    {
      "path": "test/slow/c_test.rb",
      "time_execution": 6.2120
    },
    {
      "path": "test/slow/d_test.rb",
      "time_execution": 4.3703
    }
  ]
}

HTTP status code 201

Body

Media type: application/json

Type: any

Example:

// when successfully created BuildSubset record on API side
// and Knapsack Pro client is up to date
Response does not contain any data.

// when successfully created BuildSubset record on API side
// and Knapsack Pro client is outdated
{
  "message": "Please update client knapsack_pro-ruby/rspec 2.3.0 version to 2.4.0. See CHANGELOG: https://github.com/KnapsackPro/knapsack_pro-ruby/blob/master/CHANGELOG.md#change-log"
}

HTTP status code 202

Body

Media type: application/json

Type: any

Example:

// when parallel CI node was retried too many times
{
  "message": "You retried this parallel CI node over 100 times for the CI build. Information about additional retries is not saved into our database. As a result, you won't see the latest recorded test files in the Knapsack Pro user dashboard. However, it doesn't affect your CI build - you can retry tests as many times as you like."
}

HTTP status code 422

Body

Media type: application/json

Type: any

Example:

// example 1
{
  "errors": [
    {
      "branch": ["parameter is required"]
    }
  ]
}

// example 2
{
  "errors": [
    {
      "node_index": ["must be less than or equal to 1"],
      "test_files": [
        {
          "0": {
            "time_execution": ["is not a number"]
          },
          "1": {
            "path": ["is too short (minimum is 3 characters)"]
          }
        }
      ]
    }
  ]
}

/build_distributions

/build_distributions/subset post

post

Endpoint expects a list of all test files in your test suite.

In response, you will get a list of test files that should be run on a node with particular node_index value.

You will get also build_distribution_id (seed) to compare if all your CI nodes are running based on the same test suite split.

Endpoint expects a list of all test files in your test suite.

In response, you will get a list of test files that should be run on a node with particular node_index value.

You will get also build_distribution_id (seed) to compare if all your CI nodes are running based on the same test suite split.

Request
Response

Headers

KNAPSACK-PRO-CLIENT-NAME: (string)
It is the name of library you use to connect with the API.
Example:
```
knapsack_pro-ruby
```
KNAPSACK-PRO-CLIENT-VERSION: (string)
It is the version of the library you use to connect with the API.
Example:
```
1.0.0
```
KNAPSACK-PRO-TEST-SUITE-TOKEN: required(string)
Test suite token for your project. You can get it on the user dashboard.
Example:
```
e5311882cbba506223ee8036fa68dc13
```
KNAPSACK-PRO-CI-PROVIDER: (string)
It is the name of the CI provider.
Example:
```
GitHub Actions
```

Query Parameters

fixed_test_suite_split: (boolean)
For true value it means when you run test suite again for the same commit hash and total number of nodes and for the same branch then you will get exactly the same test suite split.
Thanks to that when tests on one of your node failed then you can retry the node with exactly the same subset of tests that were run on the node in the first place.
Example:
```
true (default)
false
```
cache_read_attempt: required(boolean)
When true, then attempt to read the test suite split from the API cache.
Example:
```
true
false
```
commit_hash: required(string)
The most recent hash commit in your project.
You are running tests on the codebase with latest commit pointed to the commit_hash.
Example:
```
6e3396177d9f8ca87e2b93b4b0a25babd09d574d
```
branch: required(string)
You are running tests on this branch.
Example:
```
master
```
node_total: required(integer)
Total number of CI nodes you have.
For instance if you want to parallelize your test suite across 4 servers then node_total is 4.
Example:
```
4
```
node_index: required(integer)
Index of current CI node where part of the test suite where executed.
node_index starts from 0 so in case when node_total is 4 then max node_index is 3.
Example:
```
0
```
ci_build_id: required(string)
It is a unique number for the CI build.
ci_build_id can be integer or string.
Example:
```
1234
```
user_seat: required(string)
Who triggered the CI build, usually it's the commit author. It must be masked with a regexp pattern /(?<=\w{2})[a-zA-Z]/g. For example, John Doe <john.doe@example.com> should be masked as in the following example.
Example:
```
Jo** Do* <jo**.do*@ex*****.co*>
```
test_files: required(string)
JSON array with objects. Each object contains a test file path.
The example contains all test files in the test suite you want to run in your CI build.
When cache_read_attempt=false, then the test_files field is required to initialize a test suite split on the API side.
Otherwise, the test_files field is not needed. Do not set it in the body to save data transfer and make a fast request.
Example:
```
[
  {
    "path": "test/fast/a_test.rb"
  },
  {
    "path": "test/fast/b_test.rb"
  },
  {
    "path": "test/slow/c_test.rb"
  },
  {
    "path": "test/slow/d_test.rb"
  }
]
```
build_author: (string)
Who triggered the CI build, usually it's the commit author. It must be masked with a regexp pattern /(?<=\w{2})[a-zA-Z]/g. For example, John Doe <john.doe@example.com> should be masked as in the following example.
Example:
```
Jo** Do* <jo**.do*@ex*****.co*>
```
commit_authors: (array of object)
The authors that committed to the repository in the last month. They must be masked with a regexp pattern /(?<=\w{2})[a-zA-Z]/g. For example, John Doe <john.doe@example.com> should be masked as in the following example.
Items: CommitAuthor
- commits: required(number)
- author: required(string)
Example:
```
[
  {
    "commits": 1,
    "author": "Jo** Do* <jo**.do*@ex*****.co*>"
  }
]
```

Body

Media type: application/json

Type:

// 1st type of request to Regular Mode API should set an attribute:
// cache_read_attempt: true
// Note that there is no test_files parameter in the payload to make the request fast and keep the payload small.
{
  "fixed_test_suite_split": true,
  "cache_read_attempt": true,
  "commit_hash": "6e3396177d9f8ca87e2b93b4b0a25babd09d574d",
  "branch": "master",
  "node_total": "4",
  "node_index": "0",
  "ci_build_id": 1234,
  "user_seat": "Jo** Do* <jo**.do*@ex*****.co*>"
}

// 2nd type of request to Regular Mode API should happen if the API response for 1st type of request has the following:
// "code": "TEST_SUITE_SPLIT_CACHE_MISS"
// it means the test suite split is not cached on the API side yet.
// You must initialize a new test suite split with the following request.
// It should set the attribute:
// cache_read_attempt: false
// Note that there is a test_files attribute in the payload to initialize a test suite split based on the list of test_files from your disk.
// This request can be slow if you provide a large number of test files (~1000+).
// That is why we made the 1st request to try to read from the cache (as one of the other parallel CI nodes could have already initialized the test suite split).
{
  "fixed_test_suite_split": true,
  "cache_read_attempt": false,
  "commit_hash": "6e3396177d9f8ca87e2b93b4b0a25babd09d574d",
  "branch": "master",
  "node_total": "4",
  "node_index": "0",
  "ci_build_id": 1234,
  "user_seat": "Jo** Do* <jo**.do*@ex*****.co*>",
  "test_files": [
    {
      "path": "test/fast/a_test.rb"
    },
    {
      "path": "test/fast/b_test.rb"
    },
    {
      "path": "test/slow/c_test.rb"
    },
    {
      "path": "test/slow/d_test.rb"
    }
  ]
}

HTTP status code 200

Body

Media type: application/json

Type: any

Example:

// 1st type of response to the 1st type of request (when cache_read_attempt: true).
// It can happen only when the test suite split is not yet cached on the API side.
{
  "code": "TEST_SUITE_SPLIT_CACHE_MISS"
}

// 2nd type of response can happen for all types of requests.
// It returns a list of test files that should be run with your test runner.
{
  "build_distribution_id": "4315e028-8a17-4836-8748-42071389d48f",
  "node_index": 0,
  "test_files": [
    {
      "path": "test/fast/b_test.rb",
      "time_execution": null
    },
    {
      "path": "test/slow/d_test.rb",
      "time_execution": 3.14
    }
  ]
}

/build_distributions/last get

get

This endpoint returns a list of test files recorded for CI build that closely matches given params like commit_hash, branch, node_total.

If test files include paths to test cases then you need to merge them on your client-side to determine what test files are slow.

You need to verify if the test files still exist on your disk before running tests.

You can use the list of test files to determine what test files are slow and could be split by test cases.

knapsack_pro gem uses this API endpoint to split slow test files by test cases.

This endpoint returns a list of test files recorded for CI build that closely matches given params like commit_hash, branch, node_total.

If test files include paths to test cases then you need to merge them on your client-side to determine what test files are slow.

You need to verify if the test files still exist on your disk before running tests.

You can use the list of test files to determine what test files are slow and could be split by test cases.

knapsack_pro gem uses this API endpoint to split slow test files by test cases.

Request
Response

Headers

KNAPSACK-PRO-CLIENT-NAME: (string)
It is the name of library you use to connect with the API.
Example:
```
knapsack_pro-ruby
```
KNAPSACK-PRO-CLIENT-VERSION: (string)
It is the version of the library you use to connect with the API.
Example:
```
1.0.0
```
KNAPSACK-PRO-TEST-SUITE-TOKEN: required(string)
Test suite token for your project. You can get it on the user dashboard.
Example:
```
e5311882cbba506223ee8036fa68dc13
```
KNAPSACK-PRO-CI-PROVIDER: (string)
It is the name of the CI provider.
Example:
```
GitHub Actions
```

Query Parameters

commit_hash: required(string)
The most recent hash commit in your project.
You are running tests on the codebase with latest commit pointed to the commit_hash.
Example:
```
6e3396177d9f8ca87e2b93b4b0a25babd09d574d
```
branch: required(string)
You are running tests on this branch.
Example:
```
master
```
node_total: required(integer)
Total number of CI nodes you have.
For instance if you want to parallelize your test suite across 4 servers then node_total is 4.
Example:
```
4
```
node_index: required(integer)
Index of current CI node where part of the test suite where executed.
node_index starts from 0 so in case when node_total is 4 then max node_index is 3.
Example:
```
0
```

HTTP status code 200

Body

Media type: application/json

Type: any

Example:

{
  "build_distribution_id": "string uuid or null",
  "time_execution": 1.53,
  "test_files": [
    {
      "path": "spec/a_spec.rb",
      "time_execution": 1.0
    },
    {
      "path": "spec/b_spec.rb",
      "time_execution": 0.01
    },
    {
      "path": "spec/c_spec.rb",
      "time_execution": 0.52
    }
  ]
}

/queues

/queues/queue post

post

Endpoint expects a list of all test files in your test suite.

In response, you will get a list of test files that should be run on a node with particular node_index value. The CI node can request this endpoint multiple times til it gets an empty list of test files which means the end of the queue.

You will get also queue_name to compare if all your CI nodes are running against the same test suite queue created for particular CI build.

In response you will see build_subset_id when you have fixed_queue_split=true in request. When build_subset_id has a value then the test suite split was done based on this old recorded build subset. In that case the queue_name will be null.

Endpoint expects a list of all test files in your test suite.

You will get also queue_name to compare if all your CI nodes are running against the same test suite queue created for particular CI build.

Request
Response

Headers

KNAPSACK-PRO-CLIENT-NAME: (string)
It is the name of library you use to connect with the API.
Example:
```
knapsack_pro-ruby
```
KNAPSACK-PRO-CLIENT-VERSION: (string)
It is the version of the library you use to connect with the API.
Example:
```
1.0.0
```
KNAPSACK-PRO-TEST-SUITE-TOKEN: required(string)
Test suite token for your project. You can get it on the user dashboard.
Example:
```
e5311882cbba506223ee8036fa68dc13
```
KNAPSACK-PRO-CI-PROVIDER: (string)
It is the name of the CI provider.
Example:
```
GitHub Actions
```

Query Parameters

can_initialize_queue: required(boolean)
The first request from each CI nodes should set this field to true so the first coming request to Knapsack Pro API will initialize queue on the API side.
All next requests from each CI node should set this field to false so thanks to that when the queue will be empty on API side then the CI nodes will know that should finish work instead of initializing another queue.
Example:
```
true
false
```
attempt_connect_to_queue: required(boolean)
Should the request make an attempt to connect to existing queue on the API side? The attempt_connect_to_queue param is taken in to account by the API server only if can_initialize_queue=true.
Example:
```
true
false
```
fixed_queue_split: (boolean)
For true value it means when you run test suite again for the same commit hash and total number of nodes and for the same branch then you will get exactly the same test suite split as on the last dynamic queue split for particular CI build.
Thanks to that when tests on one of your node failed then you can retry the node with exactly the same subset of tests that were run on the node in the first place.
Example:
```
true
false (default)
```
commit_hash: required(string)
The most recent hash commit in your project.
You are running tests on the codebase with latest commit pointed to the commit_hash.
Example:
```
6e3396177d9f8ca87e2b93b4b0a25babd09d574d
```
branch: required(string)
You are running tests on this branch.
Example:
```
master
```
node_total: required(integer)
Total number of CI nodes you have.
For instance if you want to parallelize your test suite across 4 servers then node_total is 4.
Example:
```
4
```
node_index: required(integer)
Index of current CI node where part of the test suite where executed.
node_index starts from 0 so in case when node_total is 4 then max node_index is 3.
Example:
```
0
```
node_build_id: required(string)
It is the unique number of the build on CI server.
node_build_id can be integer or string.
Example:
```
1234
```
user_seat: required(string)
Who triggered the CI build, usually it's the commit author. It must be masked with a regexp pattern /(?<=\w{2})[a-zA-Z]/g. For example, John Doe <john.doe@example.com> should be masked as in the following example.
Example:
```
Jo** Do* <jo**.do*@ex*****.co*>
```
test_files: required(string)
JSON array with objects. Each object contains a test file path.
The example contains all test files in the test suite you want to run in your CI build.
When can_initialize_queue=true AND attempt_connect_to_queue=false then test_files field is required to initialize a queue on the API side.
Otherwise, the test_files field is not needed. Do not set it in the body to save data transfer and make request faster.
Example:
```
[
  {
    "path": "test/fast/a_test.rb"
  },
  {
    "path": "test/fast/b_test.rb"
  },
  {
    "path": "test/slow/c_test.rb"
  },
  {
    "path": "test/slow/d_test.rb"
  }
]
```
build_author: (string)
Who triggered the CI build, usually it's the commit author. It must be masked with a regexp pattern /(?<=\w{2})[a-zA-Z]/g. For example, John Doe <john.doe@example.com> should be masked as in the following example.
Example:
```
Jo** Do* <jo**.do*@ex*****.co*>
```
commit_authors: (array of object)
The authors that committed to the repository in the last month. They must be masked with a regexp pattern /(?<=\w{2})[a-zA-Z]/g. For example, John Doe <john.doe@example.com> should be masked as in the following example.
Items: CommitAuthor
- commits: required(number)
- author: required(string)
Example:
```
[
  {
    "commits": 1,
    "author": "Jo** Do* <jo**.do*@ex*****.co*>"
  }
]
```

Body

Media type: application/json

Type:

// 1st type of request to Queue API should set attributes:
// can_initialize_queue: true AND attempt_connect_to_queue: true
// Note that there is no test_files parameter in the payload to make the request fast and keep the payload small.
{
  "can_initialize_queue": true,
  "attempt_connect_to_queue": true,
  "fixed_queue_split": false,
  "commit_hash": "6e3396177d9f8ca87e2b93b4b0a25babd09d574d",
  "branch": "master",
  "node_total": "4",
  "node_index": "0",
  "node_build_id": "1234",
  "user_seat": "Jo** Do* <jo**.do*@ex*****.co*>"
}

// 2nd type of request to Queue API should happen only if the API response for 1st type of request has:
// "code": "ATTEMPT_CONNECT_TO_QUEUE_FAILED"
// it means an attempt to connect to the queue failed because the queue does not exist on the API side yet.
// You must initialize a new queue with the below request.
// It should set attributes:
// can_initialize_queue: true AND attempt_connect_to_queue: false
// Note that there is a test_files attribute in the payload to initialize a queue based on the list of test_files from your disk.
// This request can be slow if you provide a large number of test files (~1000+).
// That is why we did 1st request to try to connect to the existing queue first (as one of the other parallel CI nodes could have already initialized it).
{
  "can_initialize_queue": true,
  "attempt_connect_to_queue": false,
  "fixed_queue_split": false,
  "commit_hash": "6e3396177d9f8ca87e2b93b4b0a25babd09d574d",
  "branch": "master",
  "node_total": "4",
  "node_index": "0",
  "node_build_id": "1234",
  "user_seat": "Jo** Do* <jo**.do*@ex*****.co*>",
  "test_files": [
    {
      "path": "test/fast/a_test.rb"
    },
    {
      "path": "test/fast/b_test.rb"
    },
    {
      "path": "test/slow/c_test.rb"
    },
    {
      "path": "test/slow/d_test.rb"
    }
  ]
}

// 3rd type of request to Queue API should happen only if 1st or 2nd type of request returned a list of test_files.
// With the below request you can continue fetching test files from the queue to run them with your test runner.
// Request payload should have attributes:
// can_initialize_queue: false AND attempt_connect_to_queue: false
// Note there is no test_files attribute in the payload to make the request fast and keep the payload small.
{
  "can_initialize_queue": false,
  "attempt_connect_to_queue": false,
  "fixed_queue_split": false,
  "commit_hash": "6e3396177d9f8ca87e2b93b4b0a25babd09d574d",
  "branch": "master",
  "node_total": "4",
  "node_index": "0",
  "node_build_id": "1234",
  "user_seat": "Jo** Do* <jo**.do*@ex*****.co*>"
}

HTTP status code 200

Body

Media type: application/json

Type: any

Example:

// 1st type of response to the 1st type of request (when can_initialize_queue: true AND attempt_connect_to_queue: true)
// It can happen only when the queue does not exist on the API side or cannot be read from the cache on the API side
{
  "queue_name": "1:6baacadcdd493c1a6024ee7e51f018f5",
  "message": "A queue with a list of test files does not exist on the API side yet. If you see this message, everything works as expected. Now Knapsack Pro client will initialize a queue on the API side with a list of test files you want to run. The request to initialize the queue will have attributes like can_initialize_queue=true, attempt_connect_to_queue=false, and test_files, etc.",
  "code": "ATTEMPT_CONNECT_TO_QUEUE_FAILED"
}

// 2nd type of response can happen for all types of request
// It returns a list of test files that should be run with your test runner
{
  "queue_name": "1:6baacadcdd493c1a6024ee7e51f018f5",
  "build_subset_id": null,
  "test_files": [
    {
      "path": "test/slow/d_test.rb",
      "time_execution": 3.14
    },
    {
      "path": "test/fast/b_test.rb",
      "time_execution": null
    }
  ]
}

/builds

/builds get

get

Get list of all CI builds you have run. Array of CI builds is inside of data key.

There are also available pagination urls in links key so you can easily get CI builds for next page. Key meta contains basic info about current CI builds page.

You can provide optional query params to filter list of CI builds by commit_hash, branch, node_total.

Example 1: /v1/builds?page=1&branch=master&node_total=2

Example 2: /v1/builds?page=1&commit_hash=d1acb81ac1bead703eb6de64d1af24104d5d4b2c

CI build means unique combination of commit_hash, branch, node_total.

You can use id of the build to fetch detailed info about tests recorded for that CI build by doing request to /v1/builds/:id endpoint.

Get list of all CI builds you have run. Array of CI builds is inside of data key.

There are also available pagination urls in links key so you can easily get CI builds for next page. Key meta contains basic info about current CI builds page.

You can provide optional query params to filter list of CI builds by commit_hash, branch, node_total.

Example 1: /v1/builds?page=1&branch=master&node_total=2

Example 2: /v1/builds?page=1&commit_hash=d1acb81ac1bead703eb6de64d1af24104d5d4b2c

CI build means unique combination of commit_hash, branch, node_total.

You can use id of the build to fetch detailed info about tests recorded for that CI build by doing request to /v1/builds/:id endpoint.

Request
Response

Headers

KNAPSACK-PRO-TEST-SUITE-TOKEN: required(string)
Test suite token for your project. You can get it in user dashboard.
Example:
```
e5311882cbba506223ee8036fa68dc13
```

Query Parameters

commit_hash: (string)
You can filter by commit hash.
Example:
```
6e3396177d9f8ca87e2b93b4b0a25babd09d574d
```
branch: (string)
You can filter by branch name.
Example:
```
master
```
node_total: (integer)
You can filter by total number of CI nodes you have run CI build on.
For instance if you parallelized your test suite across 4 machines then node_total is 4.
Example:
```
4
```

HTTP status code 200

Body

Media type: application/json

Type: any

Example:

{
    "meta": {
        "records_per_page": 100,
        "total_pages": 1,
        "prev_page": null,
        "current_page": 1,
        "next_page": null,
        "is_first_page": true,
        "is_last_page": true,
        "is_page_out_of_range": false
    },
    "links": {
        "first": "https://api.knapsackpro.com/v1/builds?branch=master&commit_hash=d1acb81ac1bead703eb6de64d1af24104d5d4b2c&node_total=2&page=1",
        "prev": null,
        "self": "https://api.knapsackpro.com/v1/builds?branch=master&commit_hash=d1acb81ac1bead703eb6de64d1af24104d5d4b2c&node_total=2&page=1",
        "next": null,
        "last": "https://api.knapsackpro.com/v1/builds?branch=master&commit_hash=d1acb81ac1bead703eb6de64d1af24104d5d4b2c&node_total=2&page=1"
    },
    "data": [
        {
            "id": "07c0fca5-9a6c-4313-b176-25dad6139057",
            "commit_hash": "d1acb81ac1bead703eb6de64d1af24104d5d4b2c",
            "branch": "master",
            "node_total": 2,
            "created_at": "2019-09-18T17:54:54.430Z",
            "updated_at": "2019-09-18T18:02:16.149Z"
        }
    ]
}

/builds/:id get

get

Get detailed info about CI build with all build subsets containing the test files recorded timing for that CI build.

Note the CI build means unique combination of commit_hash, branch, node_total. If you will run your tests multiple times for that combination then you will get multiple recorded build subset records with test files timing for particular CI node indexes.

Get detailed info about CI build with all build subsets containing the test files recorded timing for that CI build.

Request
Response

Headers

KNAPSACK-PRO-TEST-SUITE-TOKEN: required(string)
Test suite token for your project. You can get it in user dashboard.
Example:
```
e5311882cbba506223ee8036fa68dc13
```

HTTP status code 200

Body

Media type: application/json

Type: any

Example:

{
  "id": "ba2190af-1bb1-4e3a-8ce1-37303549a4c3",
  "commit_hash": "347f33f598e5c66727e36b6f0c13b034f6a057f0",
  "branch": "master",
  "node_total": 2,
  "created_at": "2018-04-02T10:00:44.741Z",
  "updated_at": "2018-04-02T10:00:44.763Z",
  "build_subsets": [
    {
      "id": "b9f09921-939d-43a6-ae5d-7c95866b4dec",
      "node_index": 0,
      "created_at": "2018-04-21T11:18:34.539Z",
      "updated_at": "2018-04-21T11:18:34.539Z",
      "test_files": [
        {
          "path": "spec/a_spec.rb",
          "time_execution": 0.0008809566497802734
        },
        {
          "path": "spec/b_spec.rb",
          "time_execution": 0.019934892654418945
        }
      ]
    },
    {
      "id": "2fa57fa8-0ff3-4af8-980f-5788c5ab6d21",
      "node_index": 0,
      "created_at": "2018-04-21T11:18:23.750Z",
      "updated_at": "2018-04-21T11:18:23.750Z",
      "test_files": [
        {
          "path": "spec/a_spec.rb",
          "time_execution": 0.011754035949707031
        },
        {
          "path": "spec/b_spec.rb",
          "time_execution": 0.22170114517211914
        }
      ]
    },
    {
      "id": "f7a0bdda-54d6-48b2-965a-4b1a4153043d",
      "node_index": 1,
      "created_at": "2018-04-21T11:18:39.506Z",
      "updated_at": "2018-04-21T11:18:39.506Z",
      "test_files": [
        {
          "path": "spec/c_spec.rb",
          "time_execution": 0.013020992279052734
        },
        {
          "path": "spec/d_spec.rb",
          "time_execution": 0.0174105167388916
        },
        {
          "path": "spec/e_spec.rb",
          "time_execution": 0.23191308975219727
        }
      ]
    },
    {
      "id": "cd424b01-9dfc-4b6d-be5f-e8acbea6c6f3",
      "node_index": 1,
      "created_at": "2018-04-21T11:18:29.156Z",
      "updated_at": "2018-04-21T11:18:29.156Z",
      "test_files": [
        {
          "path": "spec/c_spec.rb",
          "time_execution": 0.011027812957763672
        },
        {
          "path": "spec/d_spec.rb",
          "time_execution": 0.019047812957763879
        },
        {
          "path": "spec/e_spec.rb",
          "time_execution": 0.038027712957363670
        }
      ]
    }
  ]
}

HTTP status code 404

Body

Media type: application/json

Type: any

Example:

{
  "errors": [
    "Could not find Build"
  ]
}

Knapsack Pro API documentation version v1

/build_subsets

/build_subsets post

post /build_subsets

Headers

Query Parameters

Body

HTTP status code 201

Body

HTTP status code 202

Body

HTTP status code 422

Body

/build_distributions

/build_distributions/subset post

post /build_distributions/subset

Headers

Query Parameters

Body

HTTP status code 200

Body

/build_distributions/last get

get /build_distributions/last

Headers

Query Parameters

HTTP status code 200

Body

/queues

/queues/queue post

post /queues/queue

Headers

Query Parameters

Body

HTTP status code 200

Body

/builds

/builds get

get /builds

Headers

Query Parameters

HTTP status code 200

Body

/builds/:id get

get /builds/:id

Headers

HTTP status code 200

Body

HTTP status code 404

Body