Refactor Gradle Build Tasks to Conform to Gradle Standard

[david-navapbc]

User Story

As a RS developer
When I invoke one or more Gradle tasks
Then I want the order in which those tasks were invoked to be respected
And I want the execution to be as expedient as possible

Description/Use Case

Report Stream uses gradle to compile the project, run tests, and perform other tasks related to
packaging the project. We have created several custom gradle “tasks”, many of which have
dependent relationships on other tasks. One of gradle’s primary strengths is the speed with
which it can execute builds. It accomplishes this through a combination of parallelizing tasks
and intelligently caching the results of previous task executions such that it only executes tasks
it needs to instead of executing everything every time.
That benefit comes at a cost. Gradle can be challenging to use, and, if not used in accordance
with what their manual defines as best practices, the speed benefit does not manifest.
Additionally, the guarantee of command line task order safety (the order in which gradle tasks
are invoked at the command line) may not be respected. The purpose of this ticket is to restore the guarantee of command line order safety and to meaningfully improve execution times by enabling gradle to resuse the result of previous task execution where possible.

Risks/Impacts/Considerations

None. Nothing bad will happen if we do what the manual tells us to do. We created a PoC to prove things out. See attached one sheet.

Dev Notes

See attached one sheet for context, PoC, and links to germane sections of gradle manual.

Acceptance Criteria

• all RS-defined gradle tasks that create, destroy, or alter resources are defined in gradle-standard format.
• all refactored tasks are manually executed and verified to perform as expected

Report Stream Build Challenges and Solutions.pdf