Previously, if Sonarr or Radarr added a new property to a DTO, Recyclarr
would fail when attempting to deserialize those responses. The purpose
of this was to catch compatibility issues early. However, this actually
prohibits a more useful case: Deserializing only data we care about and
having the freedom to ignore other, superfluous stuff.
Previously, only Sonarr had compatibility checking logic, which also
consequently meant that version information was obtained and logged for
Sonarr services. However, Radarr had no such checks because
compatibility has not yet been an issue. However, we still would like to
see version information printed when running Radarr instances.
Reason: Exception would be thrown when no config files are found when
invoking the various `--list` arguments. No configuration should not
prevent these from working.
The `configs` directory may now be used to automatically load YAML
configuration files. Any YAML files in that directory are loaded without
using the `--config` option.
This factory was incorrectly using an Autofac container to resolve
types. This led to symptoms like extra elements in arrays being
deserialized, due to those types being resolved by the DI container.
There's no real reason I can think of to depend on Autofac when
deserializing types from YAML. This object has been around since 1.0.0
and I do not remember why it was created.
- Get rid of `IServiceLocatorProxy`
- Get rid of `ICompositionRoot`
In addition, all unit tests avoid using `BaseCommand` directly, as it
does its own composition root setup and overrides the IntegrationFixture
test setup.
If custom formats are provided, run validation logic against them. This
also was an opportunity to make the ServiceConfiguration validation
logic reusable between Sonarr and Radarr.
Because `SHOULD_PUBLISH` is an environment variable, it isn't a true
boolean: it's a string. Update the `if:` condition logic to handle it as
a string instead.
Robert Dailey
Robert Dailey
voltron4lyfe