On Tue, 2022-05-03 at 16:20 +0000, Stefan Seifert wrote: > way 2 would be a really great solution, not sure how much effort it > is to get there. > > it would also eliminate the few "satellite" IT projects we currently > have e.g. for models and caconfig, and some other projects that have > self-baked integration tests mostly based on the older sling > packagings could be migrated as well. it's really a pain to have the > ITs in separate GIT repos, they often get overlooked and break the > whole PR-review-flow.
Right, I don't think it's going to be easy. I have a rough idea about the end goal: 1. Add Maven tooling that is able to launch a certain version of the starter ( fix number or 'latest SNAPSHOT' ) from other projects 2. Add Maven tooling to override a bundle's version directly by synthesizing additional feature model defintions behind the scenes 3. Move launchpad integration tests to the module they are testing 4. Convert launchpad integration tests so that they follow a certain convention ( JUnit runner?) so they work with an external Sling app 5. Deploy module integration tests as maven artifacts 6. Maven tooling to launch module integration tests during the starter build, probably by looking up bundles that have associated integration test artifacts. With this set into place, we should be able to run ITs in the following manager: a. Module runs its specific ITs against a Sling Starter instance ( current snapshot or release ) b. Module runs all Starter ITs against a Sling Starter instance ( current snapshot or release ) c. Sling Starter runs all ITs - both those defined in its repository and those collected from modules I think that from my outline above point 4 will be the hardest - we have lots of JUnit 3 tests and we need to find a good solution to make sure they can run in both contexts - module ITs and Starter ITs. Thanks, Robert
