Add module dependency resolution quality gate for PRs in CI
Description
Environment
Potential Workaround
relates to
Checklist
hideTestRail: Results
Activity
John Malconian March 8, 2019 at 2:25 PM
@Jakub Skoczen Based on our discussions, we decided not to do this. Instead we decided to implement this feature on release builds only (separate issue). We can revisit this later if needed.
Jakub Skoczen March 8, 2019 at 10:00 AM
@John Malconian this has been in "CODE REVIEW" for some time, has it been completed? If so, where can I see the resulting dependency check?
Ann-Marie Breaux January 15, 2019 at 9:18 PM
@John Malconian I switched this to In Code Review; if you prefer for it to be closed, then close it. Definitely not "In Review" for manual testing. Thank you!
Cate Boerema January 4, 2019 at 8:05 AM
@patty.wanninger, true. @John Malconian, In Review status means ready for the manual testers. If you are looking for a code review, please use Code Review status or close. Thanks!
patty.wanninger January 3, 2019 at 10:24 PM
@John Malconian @Cate Boerema This does not seem like a ticket for the IC testers.
All module dependency resolution checking utilizing a tenant install endpoint in Okapi (simulate-mode).
The process would look something like the following:
1) deploy an instance of okapi (probably in a container) for each PR.
2) pull all module descriptors from folio-registry.
3) generate a module descriptor for the PR's module and post to local instance of okapi.
4) generate a list of stripes modules from 'next-release' branch of platform-core or platform-complete to enable in addition/in lieu of the local module we are testing.
5) create a tenant on local okapi instance
6) use tenant's install endpoint to simulate deployment
7) tear down local okapi instance
If there is a dependency resolution conflict, the PR fails. If there is no dependency resolution conflict, but the new version of the module is not included in list of modules to enable, a warning message is generated that signifies that no modules are prepared to use the new iteration of the module. This is useful for backend modules that increment the interface version.