This PR implements the kernel impact detection algorithm.
Impact detection does NOT ask "will I be able to find this key in the cache". That's a detail of cache management. Impact detection asks only "has this target changed since this build". This allows a user to build up systems which can compare say build histories on a branch and reason about what the changes have been since the previous build, rather than simply asking what keys may not be present in the cache.
When complete, this PR will also provide machinery by which Katamari's roll extension can database and address builds, and machinery for referring to historical builds by ID and branch state. The goal should be to present an interface by which to query for changes (invalidated targets) relative to a git state.
This should make it possible to implement a test target which simply enumerates changed targets eg since some git ref, selects -test rules, builds them, and then uses an appropriate runner. That interface will be future work.
This PR implements the kernel impact detection algorithm.
Impact detection does NOT ask "will I be able to find this key in the cache". That's a detail of cache management. Impact detection asks only "has this target changed since this build". This allows a user to build up systems which can compare say build histories on a branch and reason about what the changes have been since the previous build, rather than simply asking what keys may not be present in the cache.
When complete, this PR will also provide machinery by which Katamari's
rollextension can database and address builds, and machinery for referring to historical builds by ID and branch state. The goal should be to present an interface by which to query for changes (invalidated targets) relative to a git state.This should make it possible to implement a
testtarget which simply enumerates changed targets eg since some git ref, selects-testrules, builds them, and then uses an appropriate runner. That interface will be future work.