Flesh out acceptance tests

[edwinkortman]

Spawned from: #212 (comment), #212 (comment)

The scenarios in analyze.feature are currently a little meager.

This issue is blocked until the entire happy path has been implemented. Blocked by:

• Let GitRepositoryClonedEvent.Handle pass ComputeHistoryActivity to the activity engine #205
• Let HistoryIntervalStopFoundEvent.Handle pass CheckoutHistoryActivity to the activity engine #208
• Let HistoryStopCheckedOutEvent.Handle pass DetectAgentsForDetectManifestsActivity to the Activity Engine #237
• ManifestDetectedEvent dispatch GenerateBillOfMaterialsActivity #238
• BillOfMaterialsGeneratedEvent dispatch ComputeLibYearActivity #239

To do

• Test: Run the analysis with default options, freshli analyze https://github.com/corgibytes/freshli-fixture-ruby-nokotest. Running it with just the repository passed, should lead to using all the default options.
• Test: Run the analysis with specific git installation, freshli analyze --git-path=git https://github.com/corgibytes/freshli-fixture-ruby-nokotest
• Test: Run the analysis for a specific branch. e.g. freshli analyze --branch=trunk https://github.com/corgibytes/freshli-fixture-ruby-nokotest
• Test: Run the analysis for every point in time when the files have changed. freshli analyze --commit-history https://github.com/corgibytes/freshli-fixture-ruby-nokotest
• Test: Run the analysis at a specific interval. In the example: take the last point in time per three months that files have changed. freshli analyze --history-interval=3m https://github.com/corgibytes/freshli-fixture-ruby-nokotest
• Test: Run the analysis, start with 6 workers. freshli analyze --workers=6 https://github.com/corgibytes/freshli-fixture-ruby-nokotest

[edwinkortman]

@mscottford I'm continuing our thread from #212 (comment) here.

Scott wrote:

I like that this information is being written out. It'll help show progress as the command is running along. I think the output would be more meaningful if it included the path to the manifest that's being analyzed. Many git repositories are going to have more than one dependency manifest. In those cases, you'd get this output twice for a given CommitId. Also the date maters, too... so that should be included as well. So I think the output would need to be something like

"LibYear for {manifest} at {CommitId} on {date} is {libYearSummed}". What do you think? We can also create an issue for this and have it wait until later. I wouldn't think that this is needed before we demo.

We could also write this line to the log as Information if it's going to make the console output too noisy. If we write a detailed message to the log, then I think we could just write out a . to the console to show that progress is being made.

Edwin wrote:

Haha, yeah I had the same conclusion but I didn't want to add it in this PR. Same with the acceptance tests, I wanted to wait until everything is connected before finalizing them as the tests depend on this output.

I like the idea of logging it to a log instead of the console output. Maybe add a --verbose option to see these sort of logs?