Using variables in config.yml other than {arch}

Development
1

Hello everyone,

When developing an addon, we can use {arch} as a variable for “image” option to specify the correct docker image to download for our addon.
Is it possible to use other option as an argument as well?
For example, i would like a user configurable binary version for my addon, current idea is when a user selects an option from configuration, that will be used inside docker container to form a download URL to download that binary version. For example, this:

options:
  bin_version: 2.1.1
schema:
  bin_version: list(2.1.1|2.3.1|2.4.1)

When user selects it, inside docker container, script will form URL based on that selection to download binary from example:

https://example.org/download/package-2.1.1-aarch64.bin

However i would like to build separate docker images per binary version and not sure if something like this is possible:

image: repo/{arch}-my-custom-addon-{bin_version}
### OR ###
image: repo/{arch}-my-custom-addon-{options.bin_version}

My current idea of implementation poses a potential security risk and increases addon start time because binary needs to be downloaded every time.

2

The value for arch is made available to the dockerfile as an argument. Just add ARG BUILD_ARCH if you want to use that value.

Hopefully you don’t actually mean in a script in the container. Do this in the Dockerfile with RUN so its baked into the image. Don’t make the user wait for it to fetch the same file every time the addon starts.

No you can’t do this. You can have a separate image per arch but you can’t have an addon config option which changes what image is used. Supervisor pulls/makes one image to be used when the addon is installed/updated, pulling/making multiple with an option to choose which one is used isn’t supported.

Plus how realistic is supporting that? If the diferences between bin versions are so minimal that your addon can easily support all versions then why would a user choose any version besides the latest? And if the changes aren’t all that minimal then how is your addon going to easily support all versions of the binary?

I would recommend making that choice for users and picking the best one. Remember they can always simply not update your addon if you updated to a new version of the binary that doesn’t work for them. If a different version is recommended per arch then you can do something like this in your dockerfile:

ARG BUILD_ARCH
RUN if [ "${BUILD_ARCH}" = "armhf" ]; then \
      version="2.1.1"; \
    elif [ "${BUILD_ARCH}" = "armv7" ]; then \
      version="2.3.1"; \
    else \
      version="2.4.1"; \
    fi \
    curl -L -f -s "https://example.org/download/package-${version}-${BUILD_ARCH}.bin"
3

Yeah trust me i don’t like my approach either, that’s why i went with downloading from script within container itself.

I do understand that i could use RUN but that way it will not be user configurable.

Reason why i would like for user to choose the binary version is due to client-server compatibility.

Server is kind of dependent on specific client version as per product compatibility matrix and there are two LTS versions.
Older LTS is final one and new LTS has 3 minor versions and all 3 of them need to be compatible with minor version of server. So that’s why i have 4 versions in total that user may choose from in order to be in compliance with server version.

Addon itself is for now capable of building configuration per version selected so it works correctly. Just an approach is not the best one.

Picking the best version would be difficult here unfortunately.

Is there another approach to this?
I can maybe create 4 different addons (each containing needed version) and user can choose which one to install based on client version. But in that case, is there any chance to prevent user from running an addon if another version is installed or already running on HA?

4

How big are the binaries? Is including multiple in each image reasonable or are they huge? If you can include multiple in each image then you could give the user an option and based on that option simply move one of the binaries to its expected spot. Like for example you could have this:

/etc/addon_bins
  my-custom-addon-1.1.1
  my-custom-addon-1.3.1
  my-custom-addon-1.4.1

And then based on some option your setup script moves one of those to /usr/bin/my-custom-addon (or wherever place its supposed to be run from).

5

I was thinking about that approach as well however that would increase the overall image size up to 300-400 MB.
I guest them being huge would be a users perspective, i personally don’t think that it’s too big but it’s still unreasonably large if only 1 of 4 is being used.

Now looking at the images i have on my Home Assistant installation , addons can weigh between 200 (ESPHome) to 500 (Grafana). So it’s not that big of a deal.
I might just use this approach.

1 Like