Wes Brown

Given this, I'm not going to dig too far into this.

Given this, I'm not going to dig too far into this.

Assuming adding this content to the message is correct (as per Brandon's comment), you should add a space between the '.' and 'The...'

Assuming adding this content to the message is correct (as per Brandon's comment), you should add a space between the '.' and 'The...'

Rather than having to define, load, and insert each csv file individually, is it possible to just load all the csv files in the specified folder and insert them using some kind of structured file n...

Rather than having to define, load, and insert each csv file individually, is it possible to just load all the csv files in the specified folder and insert them using some kind of structured file name (or something) to map the file to a table?

Are these type of path's and known files stored in a constants class somewhere rather than being used as magic strings?

Are these type of path's and known files stored in a constants class somewhere rather than being used as magic strings?

OK, I figured that was the case given that all the controller tests seems to be written in the same form.

OK, I figured that was the case given that all the controller tests seems to be written in the same form.

Yeah, the corrected (thanks Nikodem!) statement above seemed slightly more readable... not a big deal though.

Yeah, the corrected (thanks Nikodem!) statement above seemed slightly more readable... not a big deal though.

Can this be simplified to `return isGoingToParentTest(toState, fromState, options) || toState.isOffline;`? The current code with two negatives like this can make the logic confusing.

Can this be simplified to `return isGoingToParentTest(toState, fromState, options) || toState.isOffline;`? The current code with two negatives like this can make the logic confusing.

The fact that each of the Jenkinsfile changes are nearly (completely?) identical seems to indicate that this file should be shared somewhere (perhaps as a submodule?) rather than duplicated for eac...

The fact that each of the Jenkinsfile changes are nearly (completely?) identical seems to indicate that this file should be shared somewhere (perhaps as a submodule?) rather than duplicated for each service. Each service would then only define the service-specific settings it needs and/or any customizations that are required to the core CI/CD process. This seems to hold true for the other updates in this commit as well.

Adding this type of boolean parameters can be problematic, especially if there ever needs to be multiple boolean parameters added to the builder. Using the existing builder pattern along with a flu...

Adding this type of boolean parameters can be problematic, especially if there ever needs to be multiple boolean parameters added to the builder. Using the existing builder pattern along with a fluent interface to define this types of optional-ish parameters might be a more future-proof option that would be easier to read and understand.

This doesn't actually seem like an integration test given that many (all?) of the downstream services are mocked. While I noticed that all the tests in this test class seem to follow the same behav...

This doesn't actually seem like an integration test given that many (all?) of the downstream services are mocked. While I noticed that all the tests in this test class seem to follow the same behavior, these tests seem more like unit tests then integration tests.

Add isReportOnly parameter to javadoc comment.

Add isReportOnly parameter to javadoc comment.

The comments here should be updated to include the new parameter.

The comments here should be updated to include the new parameter.

Would it be helpful to keep the original method signature as an overload so that methods that don't care about being report-only don't have to specify a seemingly random boolean parameter?

Would it be helpful to keep the original method signature as an overload so that methods that don't care about being report-only don't have to specify a seemingly random boolean parameter?

Thanks very much for the explanation! I didn't notice the class-level Getter annotation.

Thanks very much for the explanation! I didn't notice the class-level Getter annotation.