We currently always consume whatever the latest changes are on a given branch from upstream Hermeto's integration test suite. That works fine for latest HEAD, but whenever we'd try to roll out a maintenance release we'd have to backport all the integration test changes along to make the downstream branch actually pass the integration test suite which may have potentially accumulated many changes in this very repository.
We should figure out a versioning scheme for all test scenarios such that when an update is required for new functionality or for some refactoring a new branch is created for the updated scenario, keeping the original intact. Alternatively, upstream Hermeto could consider pinning the test origin references to distinct commits.
We currently always consume whatever the latest changes are on a given branch from upstream Hermeto's integration test suite. That works fine for latest HEAD, but whenever we'd try to roll out a maintenance release we'd have to backport all the integration test changes along to make the downstream branch actually pass the integration test suite which may have potentially accumulated many changes in this very repository.
We should figure out a versioning scheme for all test scenarios such that when an update is required for new functionality or for some refactoring a new branch is created for the updated scenario, keeping the original intact. Alternatively, upstream Hermeto could consider pinning the test origin references to distinct commits.