Initialization logic has been completely overhauled. The previous
implementation was based on an approach that prioritized keeping the
composition root in the Program class. However, I wasn't happy with
this. CliFx inevitably wants to be the effective entry point to the
application. This means that the Program class should be as dumb as
possible.
The motivation for all this rework is the Recyclarr GUI. I need to be
able to share more initialization code between the projects.
Along with the initialization logic changes, I unintentionally
interleaved in another, completely unrelated refactoring. The IAppPaths
class now uses `IFileInfo` / `IDirectoryInfo` instead of `string` for
everything. This greatly simplified the implementation of that interface
and reduced dependencies and complexity across the code base. However,
those changes were vast and required rewriting/fixing a lot of unit
tests.
This sets the groundwork for making Radarr guide data available for
other usages beyond syncing to Radarr, such as spitting out information
to the console.
When you specify an empty object in YAML, like:
```
quality_profiles:
```
This causes that respective object/collection to be assigned `null`.
YamlDotNet feature request covering this behavior can be found
[here][1].
Fixes#89.
[1]: https://github.com/aaubry/YamlDotNet/issues/443
If scores are missing from a CF in either the guide or in the YAML
config, that CF is still synced but no score will be set in any quality
profiles.
The warning message for this was a bit misleading. It made users think
the CF itself would not be synced. The CF is always synced.
The message has been reworded to make this more clear and it is
downgraded from Warning to Informational.
Reason: Users may use a combination of YAML files, some may not have
both radarr and sonarr config sections in them. We should gracefully
pass over these to allow other configs to be processed.
Should the final list still be empty, the program can gracefully exit
having done no work.
The matrix build for published platforms is getting extremely large.
It's no longer efficient or productive to run the unit tests during that
job. Instead, a much smaller job is now run prior to the Build job for
running tests.
Robert Dailey