Why when I run the test suite with Knapsack Pro on the same commit hash it doesn’t create a new CI build entity in Knapsack Dashboard?

It is on purpose like that. From the Knapsack Pro dashboard perspective, CI build is a unique set (commit hash, branch name, node total). When you open a CI build in the Knapsack Pro user dashboard you will see the latest recorded time for each test file for a given commit hash.

Whenever you run a new CI build on your CI provider for the same (commit hash, branch name, node total) then this will update test timing data on the Knapsack Pro API side for existing CI build (a unique set commit hash, branch name, node total).

It is like that because Knapsack Pro backend cares about having the most up to date test timing data for a commit hash so it can use the most relevant historical tests timing data for your commit, branch that you will run tests for in the future to better predict how to split your tests in parallel CI nodes.

Second, not all CI providers generate a unique CI build ID so there was no simple way to identify unique CI build on the Knapsack Pro API side for all CI providers. Hence we made a decision to build the Knapsack Pro API architecture where CI build from Knapsack Pro point of view is unique (commit hash, branch name, node total). This allows Knapsack Pro API to be used as a CI provider agnostic solution (it can work with all CI providers) while at the same time maintain the ability to track the most recently recorded tests timing data so you can get most out of Knapsack Pro API when you run your tests in parallel.

The main purpose of the Knapsack Pro dashboard is to help adjust your CI configuration to get more time savings when you run parallel tests. That is why you can sometimes see yellow tips showing what to do to save more time when you open one of CI builds for a given commit from the Knapsack Pro user dashboard.