* POST release deferred cleanup
* Fixes
* One more test fix
* Test fixes
* Test fixes
* Test cleanup
* Test fixes
* Fixes
* ValueSet cleanup
* Test fix
* Test fixes
* Fixes
* Test fixes
* Fixed
* Test fixes
* Test fixes
* Test fixes
* Test fixes
* Test fixc
* Build fix
* Fix merge artifact
* Build fix
* Work on tests
* Test fixes
* Work
* Fixes
* Changelog fix
* Add changelog
* Test fix
* Test fixes
* Fixes
* Test fixes
* Test fixes
* Test fixes
* Test fix
* Tests
* Bumps
* Fixes
* Add errorprone
* Drop bz2 bins
* POM fix
* Build fix
* Update
* Test fix
Co-authored-by: James Agnew <james@jamess-mbp.lan>
* create fhir-version specific hapi-fhir-jpaserver-test projects
* moved dstu2 tests out to dstu2 test project.
* moved dstu2 tests out to dstu2 test project.
* finished moving dstu2 tests out to dstu2 test project.
* finished moving dstu2 tests out to dstu2 test project.
* dstu3 test project compiles
* start moving dstu3 resources
* letting azure pileine know about the new modules
* finished moving dstu3 resources. this might pass
* OK this one should pass for sure
* OK this one should pass for sure
* change test poms to test scope
* move the rest of R4 test classes
* move the rest of R4 test classes
* moar r4 moves
* moar r4 moves
* moar r4 moves
* finished with r4
* finished with r4
* started r5
* started r5
* Cache busting based on source branch name
* Fix other cache key
* cache pegged to SHa1
* test cleanup
Co-authored-by: Ken Stevens <ken@smilecdr.com>
Co-authored-by: markiantorno <markiantorno@gmail.com>
Co-authored-by: Tadgh <garygrantgraham@gmail.com>
This PR changes the way HAPI is built by Azure pipelines. Instead of a FIFO queue for all tests in the project, the entire project is quickly built and cached without testing, then the individual modules are built and tested in separate jobs which can be run in parallel from each other. Each of these jobs then uploads the test coverage for that module as a build artifact. Finally, a last stage downloads all the archived tests results and aggregates them using jacoco so they can be uploaded to codecov.
This has two key benefits:
If there is a failing test because of an intermittent, the individual failing module can be re-run instead of having to re-run the whole project build.
The build time is decreased substantially (90min -> 45min).
This is the first run at this, I will be iterating to further reduce build times going forward.
James Agnew
VK-SMILECDR
Mark Iantorno
Ken Stevens
Tadgh