Buildarr

Latest version: v0.7.1

Safety actively analyzes 687918 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 1 of 3

0.8.0b1

This is the first in a series of pre-releases (betas) for Buildarr v0.8, that will contain a number of new features, upgrades and refactors to future-proof Buildarr to allow for further development.

Creating pre-releases makes testing plugins easier while they are being upgraded to support the new version.

The two major features of this beta release are:

* Upgrade Buildarr to Pydantic V2.
* Improve volume handling in the `buildarr compose` command so that it generates modern long-form style syntax for service volume definitions. On Windows, it also now generates Unix-style mount points suitable for use in Docker Desktop.

For more information on what has changed, refer to the pull requests linked below.

Added

* Add unit/functional tests and coverage checks ([185](https://github.com/buildarr/buildarr/pull/185))

Changed

* Replace Poetry with PDM ([183](https://github.com/buildarr/buildarr/pull/183))
* Replace Black with the Ruff formatter ([184](https://github.com/buildarr/buildarr/pull/184))
* Improve volume handling in the `buildarr compose` command ([188](https://github.com/buildarr/buildarr/pull/188))
* Upgrade to Pydantic V2 ([196](https://github.com/buildarr/buildarr/pull/196))

0.7.1

This is a backwards-compatible release that improves the Buildarr plugin API.

When using the `BaseEnum` attribute type, plugins are now able to specify multiple possible values for an enumeration by setting a `tuple` with all values defined in it.

This allows more flexibility in the range of values users can define in the Buildarr configuration file, and makes it possible to control how those values are serialised when dumping remote instance configurations.

It also makes it possible to add JSON/YAML encoders for custom types in the Buildarr configuration model from the plugin side, when custom types that are not appropriate to add to Buildarr Core directly are required.

Changed

* Configuration encoding and type improvements ([164](https://github.com/buildarr/buildarr/pull/164))
* Fix bugs in multi-value `BaseEnum` ([165](https://github.com/buildarr/buildarr/pull/165))

0.7.0

This is a **backwards-incompatible** feature and bugfix release.

From a user perspective, the main change in this release is that `secrets.json` is no longer generated, and no longer used by Buildarr.

When Buildarr was originally designed, it was normal for Sonarr and Radarr to expose their API keys on their `initialize.js[on]` endpoints, allowing them to be dynamically fetched. To avoid doing this every time, the `secrets.json` file was used to cache them.

However, since then, a few issues have become glaringly obvious:

* The `secrets.json` file is difficult to manage from a security standpoint, as it is unencrypted and is not created using a secure `umask` by Buildarr by default at the moment.
* Whenever plugins have a major update and have no means of migrating older secrets model objects, older `secrets.json` files will cause validation errors when running the updated versions.
* With new versions of Arr suite applications moving to a forced-authentication model, where the API key must be provided by the client, there is simply no need to cache these credentials in a separate file anymore.

After upgrading Buildarr, it is recommended to:

* Remove any existing copies of `secrets.json` from your Buildarr deployment.
* If using Buildarr in Docker, change your `/config` bind mount to be read-only for better security.

A couple of other issues have also been addressed in this release.

* When an error occurs during update runs in daemon mode, instead of quitting Buildarr, catch the error, log it and schedule following update runs as normal.
* This makes it easier to troubleshoot issues, as Buildarr will not continually try to execute update runs when configured to re-run after it quits unexpectedly.
* Fix a bug where after the first scheduled update run finishes in daemon mode, the "next update run" as reported by Buildarr is the same run that just executed.

The plugin API has been updated with the following changes.

* Add the following commonly used constrained string types to Buildarr Core:
* `LowerCaseNonEmptyStr`
* `LowerCaseStr`
* `UpperCaseNonEmptyStr`
* `UpperCaseStr`
* Add the new `ConfigBase.log_delete_remote_attrs` method, for more verbose logging of deleted resources.
* Reimplement the `Password` attribute type as a subclass of `SecretStr` (instead of using `Annotated`), to allow it to be subclassed and used itself in `Annotated` statements.
* Remove `json5` as a dependency of Buildarr Core. If a plugin requires this dependency, it should specify it explicitly.

Added

* Add new constrained string types ([157](https://github.com/buildarr/buildarr/pull/157))
* Add the `ConfigBase.log_delete_remote_attrs` method ([158](https://github.com/buildarr/buildarr/pull/158))

Changed

* Log errors during daemon update runs without exiting ([151](https://github.com/buildarr/buildarr/pull/151))
* Fix the next run time after scheduled runs ([152](https://github.com/buildarr/buildarr/pull/152))
* Change `Password` to be an actual subclass of `SecretStr` ([156](https://github.com/buildarr/buildarr/pull/156))
* Update dependencies ([159](https://github.com/buildarr/buildarr/pull/159))

Removed

* Remove `secrets.json` ([155](https://github.com/buildarr/buildarr/pull/155))

0.6.2

This is a backwards-compatible feature release that makes using multiple configuration files more flexible.

Buildarr allows you to split your configuration into multiple files using the `includes` option.

Before this release, however, there was a limitation to this functionality: each individual file had to be a valid configuration file on its own, and each file had to parse correctly when validated.

`prowlarr.yml`:

yaml
---

includes:
- prowlarr-2.yml

prowlarr:
instances:
prowlarr:
api_key: xxxx
settings:
indexers:
indexers:
definitions:
"Nyaa.si":
type: nyaasi
enable: true
sync_profile: Standard
redirect: false
priority: 15
grab_limit: 50 Overridden in the included file.
query_limit: 10010
fields:
torrentBaseSettings.seedRatio: null
prefer_magnet_links: true


`prowlarr-2.yml`:

yaml
---

prowlarr:
instances:
prowlarr:
settings:
indexers:
indexers:
definitions:
"Nyaa.si":
type: nyaasi Already defined, but must be defined here to work.
sync_profile: Standard Already defined, but must be defined here to work as well.
grab_limit: 104 Override the value in the original file.


With this release, this limitation has now been eliminated. The above example can now be simplified to the following, and it will work as expected:

yaml
---

prowlarr:
instances:
prowlarr:
settings:
indexers:
indexers:
definitions:
"Nyaa.si":
grab_limit: 104 Override the value in the original file.


This makes it possible to more freely structure your configuration files, e.g. splitting secret parameters (e.g. API keys and passwords) into a separate file from the main configuration.

For more information, check the configuration documentation.

Changed

* Allow any configuration value to be defined in any file ([146](https://github.com/buildarr/buildarr/pull/146))

0.6.1

This is a backwards-compatible feature release that adds built-in support for parsing, decoding and encoding email attribute types that include a name (e.g. `Example Admin <adminexample.com>`).

Some plugins use this attribute type (`NameEmail` in Pydantic) without explicitly defining parameters for parsing it, so this adds sane defaults for that attribute type to ensure parsing works appropriately.

This will not be done for every possible type, but this application is generic and common enough that it is advantageous to build it into the core Buildarr application.

Added

* Add built-in support for handling NameEmail attribute types ([138](https://github.com/buildarr/buildarr/pull/138))

0.6.0

This is a backwards-compatible feature and bugfix release.

The main addition is a new run stage for Buildarr plugins: post-initialisation rendering. This is similar to the existing (henceforth called pre-initialisation) rendering stage, but runs after the instance initialisation stage. This allows it to expose the instance secrets, giving the plugin access to the remote instance while rendering the configuration.

This can be useful for things such as resolving select option names from names via the API schema, which is sometimes used when rendering TRaSH-Guides metadata. The new stage is used in the upcoming Radarr plugin for Buildarr.

The following issues have also been resolved:

* Buildarr daemon stopped watching configuration file changes, if an unexpected error occurred while performing the initial run following reloading the configuration files.

Added

* Add post-initialisation rendering step ([126](https://github.com/buildarr/buildarr/pull/126))

Changed

* Detect plugins that do not use config rendering ([116](https://github.com/buildarr/buildarr/pull/116))
* Fix running plugins that do not perform config rendering ([132](https://github.com/buildarr/buildarr/pull/132))
* Improve daemon reloading ([131](https://github.com/buildarr/buildarr/pull/131))

Page 1 of 3

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.