YamlSerializerFactory continues to grow as we add parsing features to
YAML files. A new behavior system now provides granular sets of features
to the factory. To extend the functionality of the YAML parser,
implement the `IYamlBehavior` interface. It will automatically be
registered to Autofac and injected into `YamlSerializerFactory`.
This was caused by a logic error that thought that a file was empty just
because it didn't find any configuration data relevant to the current
subcommand. For example, a config file that only has Radarr config in it
when you run `recyclarr sonarr`.
- Better contextual logging for YAML files
- When there's a syntax error in file parsing, skip that file.
- When validation fails for instance config, skip just that instance.
- If a file is empty, print a warning and skip it.
- Print instance name (instead of URL) in more places.
The goal is to eliminate the need for a "global setup" step for HTTP
communication. This can instead be done in the composition root as part
of the factory to request FlurlClient objects.
- Simplify the comment style for YAML intended to be uncommented by the
user. Now they just need to delete the leading hash and YAML will be
at the appropriate indentation.
- Add additional explanation at the top about how to set up
configuration based on the guide.
- Fix link to the configuration reference.
Some types do not get registered until later on after
CompositionRoot.Setup() is called. Use IntegrationFixture to fulfill
mock versions of those types.
This library was causing numerous issues related to git operations. The
straw that broke the camel's back is that it does not do automatic
garbage collection (`git gc --auto`). So a user's repo directory
continues to grow in size.
The replacement is CliWrap, which is just a simple wrapper library that
allows easy execution of shell commands. Specifically, `git` commands.
BREAKING CHANGE: This change now requires the `git` executable to be
installed by the user if run on a host system. The git executable will
be provided automatically for the docker image.
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.
BREAKING CHANGE: The deprecated feature that still allowed you to keep
your `recyclarr.yml` next to the executable has been removed. Your
`recyclarr.yml` configuration file must now be located in your
application data directory
The introduction of lifetime scopes inside of configuration processing
in the Command classes introduced issues with the way resolution
overrides happened especially with integration test fixtures.
When using multiple instances of Sonarr at v4 and v3, it was possible to
get a VersionException due to stale information carrying over between
processing instances.
Version enforcement was only running if the user specified release
profiles because that logic was unintentionally tightly coupled to them.
Now that logic runs regardless of whether the user is using RPs or CFs.
When logging HTTP response/request bodies during communication with
Radarr, Sonarr, etc, use a compact form instead. The previous form had
newlines in it which ended up making the logs vertically very long and
hard to follow.
When using `--list-custom-formats` with either the `sonarr` or `radarr`
subcommand, custom formats will be grouped according to the respective
tables at the top of the "Collection of custom formats" page.
A new `log_janitor` setting added to `settings.yml` to allow the user to
specify the maximum number of files to keep when doing log cleanup.
Additionally, the way startup tasks occur has been cleaned up /
refactored to make it easier to integration test.
Simplify the factory pattern so that it creates settings more directly
instead of using a silly setter method.
Also implemented `IntegrationFixture` for easier integration testing.
In order to improve the stability and predictability of releases, I'm
favoring fixed version numbers over wildcards. This means upgrades will
be more tedious, but at least it will be easier to audit when things
break due to third party libraries.
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.
Specify `RECYCLARR_APP_DATA` so that every command inherits and uses
that path for its application data. This behaves the same as if you had
specified the `--app-data` option for every invocation of Recyclarr.
Due to the failures related to symlinks in the repo directory that
happened when doing a full directory merge, the migration logic has been
simplified. It now only copies useful YAML files and cache data. The
repo directory is ignored and will need to be re-cloned when the user
runs `recyclarr` next time.
Symlinks are difficult to deal with. At this point, it was still failing
to migrate the `.config/recyclarr/repo` directory. Even though it still
doesn't work 100%, I'm going to leave it as it is and instead simplify
what gets migrated later.
Smarter migration logic that does a directory merge instead of a
straight move. This is designed to fail less in cases like the
`recyclarr` directory already existing.
Automatic migration no longer takes place. Instead, the user must run
`recyclarr migrate` to have those migration steps executed
automatically, or do it manually.
The logger, which also writes to a file in addition to console,
requires `IAppPaths` in order to find the directory to place the log
files. However, this cannot be obtained until the system calculates
the app data directory OR the user specifies it with the `--app-data`
option.
A custom sink has been added that will allow the logger to write to
console without file logs until that initialization is performed and
the log directory is available.
- Attempt to detect if `HOME` is defined and available. If not, error
out.
- Attempt to create `$HOME/.config` if `$HOME` is available.
- If logic in code attempts to grab the app data dir path before it's
set up, an exception is thrown.
Tests fail inconsistently between Linux & Windows if you hard-code paths
with forward or backward slashes. My hope was that `MockFileSystem`
converted the slashes for me, to assist in simpler unit testing.
The default is now located at `~/.config/recyclarr/recyclarr.yml`. The
previous location (next to the executable) is still supported, but
deprecated. A `recyclarr.yml` at the old/previous location will always
be loaded first.
Robert Dailey
Robert Dailey
voltron4lyfe
snoopy82481
Jonas Geiler